SQL Server 2016: агрегатный оконный оператор пакетного типа | Оконные функции смещения, функции LAG и LEAD

Содержание:
1. Строки с разделителями UNBOUNDED и CURRENT ROW;
2. RANGE с разделителями UNBOUNDED и CURRENT ROW;
3. Разделители, отличные от UNBOUNDED и CURRENT ROW;
4. Оконные функции смещения, функции LAG и LEAD (Вы читаете данный раздел);
5. Функции FIRST.VALUE и LAST.VALUE.

Оконные функции смещения

Язык Т-SQL обеспечивает выполнение двух пар оконных функций смещения. Функции LAG и LEAD возвращают элемент из предыдущей или последующей строки соответственно. Функции FIRSTVALUE и LAST VALUE возвращают элемент из первой или последней строки окопного фрейма соответственно.

Функции LAG и LEAD

Приведенный в коде выше запрос к таблице Transactions (я буду называть его Query 8) демонстрирует традиционную — в построчном режиме применительно к данным в представлении rowstore — оптимизацию для функции LAG (функция LEAD оптимизируется аналогичным образом).

Программа преобразует функции LAG и LEAD в функцию LAST_ VALUE с фреймом, содержащим только запрашиваемую строку. Так, функция LAG со смещением, по умолчанию равным 1, преобразуется в функцию LAST_VALUE с фреймом ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING. Поэтому запрос Query 8 как по значению, так и по методу оптимизации эквивалентен запросу в коде выше (назовем его Query 9).

План выполнения запросов Query 8 и Query 9 показан на рисунке выше.

Как видите, этот план подобен тому, что был предложен для запроса Query 1 на рисунке выше. Вот какие статистические показатели я получил при его выполнении: продолжительность — 33 секунды, процессор — 32 секунды, логические операции считывания — 31 К. записи — 0.

Если в опрашиваемой таблице имеется индекс columnstore, SQL Server может оптимизировать функции LAG и LEAD с помощью оператора пакетного режима Window Aggregate; нужно только, чтобы показатель смешения был равен 1 (значение по умолчанию). К примеру, запрос в коде выше (я буду называть его Query 10) к таблице TransactionsCS демонстрирует обработку данных в пакетном режиме после оптимизации columnstore.

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

Как видите, данный план аналогичен плану, предложенному для запроса Query 2 на рисунке выше. Это план параллельный. Поскольку данные извлекаются из индекса columnstore, их необходимо сортировать. Почти все операторы используют пакетный режим обработки. Вот статистические данные, полученные мною при выполнении этого запроса: продолжительность — 10 секунд, процессор— 19 секунд, логические операции считывания — 6К, записи — 0. Обратите внимание на сокращение времени выполнения с 33 до 10 секунд.

Показанный в коде выше запрос к таблице Transact ions DCS (я буду называть его Query 11) демонстрирует обработку данных в пакетном режиме после оптимизации rowstore.
План выполнения данного запроса представлен на рисунке ниже.