SQL Server: оператор WHERE. WHERE и псевдонимы столбцов. Часть I

Содержание:
1. WHERE для фильтрации, ON для сопоставления;
2. ~~Аргументы поиска и равенство против отличия. Часть I~~ (Вы читаете данный раздел);
3. Аргументы поиска и равенство против отличия. Часть II;
4. Аргументы поиска и равенство против отличия. Часть III;
5. Укороченная операция;
6. WHERE и псевдонимы столбцов.

Хотя главная тема этой статьи — логическая обработка запросов, я хочу уделить внимание описанию некоторых сторон физической обработки запросов и областям, в которых она отличается от логической обработки. Когда речь идет о настройке запросов, важно усвоить одну из базовых концепций — аргумента поиска (или, сокращенно, SARG). SARG — предикат фильтрации, позволяющий использовать индекс способом, основанным на его упорядочении, например при поиске. Типовая форма SARG выглядит следующим образом:

WHERE <имя_столбца> <оператор> <выражение>

Этот оператор должен представлять последовательный диапазон выбранных строк в индексе по фильтрованному столбцу. Он может быть =, >, >=, <, AND = AND < и т.д. Но он не может быть О, например. Фильтрованный столбец не должен затрагиваться при различных манипуляциях. Выражением на другой стороне оперировать можно. Например, ниже приведен SARG:

WHERE coll >@p

Если имеется индекс для столбца coll, SQL Server может применить поиск в индексе для работы с фильтром. Показанное ниже не SARG, так как вы выполняете действия по отношению к фильтрованному столбцу:

WHERE coll +1 > @p

Поэтому SQL Server придется сканировать данные вместо использования поиска в индексе. В этом случае вы можете легко преобразовать фильтр в SARG, вычитая 1 из @p вместо добавления к coll, например, это SARG:

WHERE coll > @p — 1

Почему в оптимизаторе SQL Server не применяется такая внутренняя реорганизация? Действительно, в большинстве случаев этого не происходит. Возможно, компания Microsoft предпочла не вводить такую логику в оптимизатор, чтобы процесс оптимизации не занимал слишком много времени и, следовательно, не терял смысла. В случаях, когда удается предоставить пользователю простые рекомендации, отсутствие такой логики повышает эффективность процесса оптимизации.

Другой пример: следующий запрос (назовем его Query 1) представляет собой запрос с аргументом поиска, поскольку предикат фильтрации не выполняет манипуляций с фильтрованным столбцом:

SELECT custid, country, region FROM Sales.Customers WHERE region = N'WA’;

Прежде чем выполнить запрос, создайте следующий индекс для поддержки фильтра:

CREATE INDEX idx_rgn_i_cid_ctry ON Sales.Customers (region)
INCLUDE (custid, country);

План для запроса Query 1

План выполнения для запроса 1 показан на рисунке выше.

Обратите внимание, что фильтр предиката применяется как предикат поиска, поскольку рассматривается как SARG.

Следующий запрос (именуется Query 2) фильтрует только клиентов из регионов, начинающихся с буквы W:
SELECT custid, country, region FROM Sales.Customers
WHERE LEFT (region, 1) = N'W’;