В SQL Server запрос к индексируемому столбцу неожиданно получает план со сканированием. Объясните механизм на примере несовпадения типов параметра и столбца:
CREATE TABLE dbo.Clients (
ClientCode varchar(20) NOT NULL,
Name varchar(100) NOT NULL
);
CREATE INDEX IX_Clients_ClientCode
ON dbo.Clients (ClientCode);
DECLARE @code nvarchar(20) = N'ABC123';
SELECT Name
FROM dbo.Clients
WHERE ClientCode = @code;
В SQL Server сравнение varchar со значением nvarchar может вызвать неявное преобразование типов. Из-за приоритета типов SQL Server способен преобразовать индексируемый varchar-столбец к nvarchar, поэтому обычный поиск по индексу становится невозможным или менее эффективным, и оптимизатор выбирает сканирование.
Исправление — согласовать тип параметра с типом столбца, например объявить параметр как varchar(20). Преобразование самого параметра обычно сохраняет возможность индексного поиска, тогда как преобразование столбца ухудшает доступ.
Индексы создавались для быстрого поиска по значениям без чтения всей таблицы. Однако SQL поддерживает сравнение выражений разных типов, поэтому СУБД должна привести их к совместимому типу перед сравнением.
Механизм приоритета типов позволяет выбрать направление такого преобразования автоматически. Это удобно для корректности запросов, но может конфликтовать с физическим устройством индекса: индекс построен по исходному типу столбца, а не по результату преобразования каждой строки.
В примере индекс хранит значения ClientCode как varchar, а переменная имеет тип nvarchar. Если SQL Server преобразует каждое значение столбца перед сравнением, условие фактически становится похожим на CONVERT(nvarchar(20), ClientCode) = @code.
Такое преобразование может сделать предикат несопоставимым с ключом индекса. Последствия — сканирование таблицы или индекса, большее число операций CPU и чтения, а на больших объёмах — существенное увеличение времени ответа.
Важно, что окончательный план зависит от типов, колlation, версии SQL Server, структуры индексов и оценки стоимости. Сам факт наличия преобразования не означает автоматически полный скан, но это серьёзный сигнал при анализе плана.
SQL Server выбирает тип с более высоким приоритетом. Для пары varchar и nvarchar приоритет обычно выше у nvarchar, поэтому преобразование может применяться к значениям varchar в таблице.
Теперь типы совпадают, и оптимизатор может использовать Index Seek по IX_Clients_ClientCode. Преобразование параметра, если оно вообще потребуется на границе выполнения, не требует преобразования каждого индексного ключа.
Проверять проблему следует по фактическому или оценочному плану выполнения. Нужно искать предупреждение о CONVERT_IMPLICIT, анализировать предикат оператора Index Scan или Index Seek, а также сравнивать логические чтения через SET STATISTICS IO ON.
Не каждое неявное преобразование вредно одинаково. Если преобразование выполняется над константой или параметром, индексный поиск может сохраниться. Кроме того, для некоторых сочетаний типов оптимизатор способен построить эффективный seek несмотря на преобразование, поэтому решение принимают по плану и измерениям, а не только по тексту запроса.
Исправлять проблему можно согласованием типов в схеме, параметрах приложения и хранимых процедурах. Явное преобразование параметра иногда помогает, но преобразование столбца в условии, например CONVERT(nvarchar(20), ClientCode) = @code, обычно закрепляет проблему и не является универсальным исправлением.
В API поле клиентского кода хранилось как varchar(20), но драйвер передавал все строковые параметры как nvarchar. Запрос по уникальному коду выполнял сканирование индекса и при высокой конкуренции создавал заметную нагрузку на CPU и подсистему ввода-вывода.
Рассматривались три варианта. Добавление индекса по выражению с преобразованием могло ускорить именно этот запрос, но увеличило размер индексов и стоимость изменений данных. Переписывание условия через преобразование столбца было простым, однако сохраняло вычисление для каждой строки. Изменение типа параметра на varchar(20) устраняло причину без нового индекса.
Выбрали согласование типов в контракте доступа к данным и добавили проверку типов параметров в интеграционные тесты. После этого план сменился на Index Seek, а число логических чтений существенно снизилось; точный выигрыш зависел от размера таблицы и селективности кода.
CONVERT_IMPLICIT означает, что индекс не используется?Нет. Важны направление преобразования и конкретный тип доступа. Если преобразуется параметр или константа, SQL Server всё ещё может выполнить Index Seek. Даже преобразование столбца иногда сопровождается использованием индекса, но может превратить поиск в менее селективный скан или добавить вычисление. Вывод делают по оператору, предикату и фактическим затратам.
varchar и nvarchar?Тип влияет не только на представление значения, но и на правила сравнения, приоритет типов и возможность сопоставить условие с ключом индекса. При несовпадении SQL Server должен обеспечить корректную семантику сравнения, а выбранное направление преобразования меняет стоимость доступа. Поэтому текстовое значение ABC123 само по себе не определяет план — важен тип параметра.
Не всегда. Новый индекс по тому же varchar-столбцу не устранит преобразование, если оптимизатор по-прежнему должен преобразовывать значения столбца. Индекс по вычисляемому выражению может быть вариантом в конкретной СУБД, но он увеличивает стоимость вставок и обновлений и требует соблюдения условий детерминированности и сопоставимости выражения. Обычно предпочтительнее исправить типы на границе приложения или процедуры.