SQL Server: поиск или сканирование. Полусоединения и антиполусоединения

Содержание:
1. Сканирование против поиска;
2. Полусоединения и антиполусоединения (Вы читаете данный раздел);
3. N верхних позиций для группы.

---

Полусоединения[/center]
Оптимизируя запросы с помощью предиката EXISTS (или других методов) при обработке полусоединений и антиполусоединений, оптимизатор, безусловно, способен проанализировать потенциальные планы, один из которых включает сканирование, а другой — цикл операций поиска по индексу применительно к таблице большего размера. В действительности вопрос выходит далеко за рамки простого выбора между сканированием и циклом операций поиска, так как существует три алгоритма соединения (вложенные циклы, слияние и хеш-соединение). Однако я исхожу из того, что оптимизатор потенциально способен выбрать идеальную стратегию, помимо прочего, на основе характеристик данных. В качестве примера рассмотрим два запроса для случая полусоединения (см. код ниже). Планы этих запросов показаны на скриншоте выше. План первого запроса с высокой плотностью элемента «секционирование» предусматривает выполнение операций поиска по индексу применительно к таблице Orders. План второго запроса с низкой плотностью элемента «секционирование» предполагает сканирование индекса таблицы Orders.



Для следующих двух запросов существует аналогичный динамический выбор оптимизатора для случая антиполусоединений (см. код ниже). Планы этих запросов показаны на скриншоте выше.


Опять-таки в случае низкой плотности план предусматривает использование сканирования, а в случае высокой плотности — операции поиска.


Задача min или max предполагает вывод минимального или максимального значения для каждой группы. Наиболее естественный путь решения такой задачи — простой групповой запрос. При наличии PO-индекса (элемент C здесь неактуален) оптимизатор теоретически может оценить плотность столбца группы и в соответствии с результатом оценки выбрать наилучшую стратегию — сканирование или цикл операций поиска. Однако на сегодня в оптимизаторе не реализована логика выполнения цикла операций поиска для группового запроса. Таким образом, независимо от плотности, план будет предусматривать сканирование индекса. Это хорошо при низкой плотности (например, для группы, собранной по атрибуту custid), но плохо при высокой (например, для группы, собранной по атрибуту empid).

Для демонстрации примера выбора неоптимальной стратегии рассмотрим следующий запрос:

- Логических чтений 3474 
SELECT empid, MAX(orderid) AS maxoid 
FROM dbo.Orders 
GROUP BY empid;

План этого запроса — первый на скриншоте выше.

Если нужен план, в котором поиск применяется к каждому сотруднику компании, то решение необходимо переработать. Один из способов предполагает использование оператора CROSS APPLY:

- Логических чтений 4 + 670 
SELECT E.empid, O.orderid 
FROM dbo.Employees AS E CROSS APPLY (SELECT TOP (1) O.orderid 
FROM dbo.Orders AS O 
WHERE O.empid = E.empid) AS O; 

План этого запроса — второй на скриншоте выше.

Как мы видим, это искомый план. Если вас удивляет, зачем нужно использовать оператор CROSS APPLY, а не просто скалярный коррелированный подзапрос, то напомню, что CROSS APPLY убирает строки левой таблицы, не имеющие соответствий, что в данном случае предпочтительно.