Почему существуют различия в плане выполнения между OFFSET… FETCH и старой схемой ROW_NUMBER?

Новая OFFSET ... FETCHмодель, представленная в SQL Server 2012, предлагает простую и быструю подкачку страниц. Почему вообще существуют различия, если учесть, что эти две формы семантически идентичны и очень распространены?

Можно предположить, что оптимизатор распознает оба и оптимизирует их (тривиально) в полной мере.

Вот очень простой случай, когда OFFSET ... FETCH~ в 2 раза быстрее в соответствии с оценкой стоимости.

SELECT * INTO #objects FROM sys.objects

SELECT *
FROM (
    SELECT *, ROW_NUMBER() OVER (ORDER BY object_id) r
    FROM #objects
) x
WHERE r >= 30 AND r < (30 + 10)
    ORDER BY object_id

SELECT *
FROM #objects
ORDER BY object_id
OFFSET 30 ROWS FETCH NEXT 10 ROWS ONLY

Можно изменить этот контрольный пример, создав CI object_idили добавив фильтры, но удалить все различия планов невозможно. OFFSET ... FETCHвсегда быстрее, потому что он выполняет меньше работы во время выполнения.

Примеры, приведенные в вопросе, не дают одинаковых результатов (в OFFSETпримере есть ошибка «один за другим»). Обновленные формы ниже исправляют эту проблему, удаляют дополнительную сортировку для ROW_NUMBERслучая и используют переменные, чтобы сделать решение более общим:

DECLARE 
    @PageSize bigint = 10,
    @PageNumber integer = 3;

WITH Numbered AS
(
    SELECT TOP ((@PageNumber + 1) * @PageSize) 
        o.*,
        rn = ROW_NUMBER() OVER (
            ORDER BY o.[object_id])
    FROM #objects AS o
    ORDER BY 
        o.[object_id]
)
SELECT
    x.name,
    x.[object_id],
    x.principal_id,
    x.[schema_id],
    x.parent_object_id,
    x.[type],
    x.type_desc,
    x.create_date,
    x.modify_date,
    x.is_ms_shipped,
    x.is_published,
    x.is_schema_published
FROM Numbered AS x
WHERE
    x.rn >= @PageNumber * @PageSize
    AND x.rn < ((@PageNumber + 1) * @PageSize)
ORDER BY
    x.[object_id];

SELECT
    o.name,
    o.[object_id],
    o.principal_id,
    o.[schema_id],
    o.parent_object_id,
    o.[type],
    o.type_desc,
    o.create_date,
    o.modify_date,
    o.is_ms_shipped,
    o.is_published,
    o.is_schema_published
FROM #objects AS o
ORDER BY 
    o.[object_id]
    OFFSET @PageNumber * @PageSize - 1 ROWS 
    FETCH NEXT @PageSize ROWS ONLY;

ROW_NUMBERПлан имеет ориентировочную стоимость 0.0197935 :

OFFSETПлан имеет ориентировочную стоимость 0.0196955 :

Это экономит 0,000098 единиц расчетной стоимости (хотя OFFSETплан потребует дополнительных операторов, если вы хотите вернуть номер строки для каждой строки). OFFSETПлан еще будет немного дешевле, вообще говоря, но помните , что сметные расходы именно это - реальное тестирование еще требуется. Большая часть затрат в обоих планах - это стоимость полного набора входных данных, поэтому полезные индексы будут полезны для обоих решений.

Если используются постоянные литеральные значения (например, OFFSET 30в исходном примере), оптимизатор может использовать сортировку TopN вместо полной сортировки, за которой следует Top. Когда строки, необходимые из сортировки TopN, являются константным литералом и <= 100 (сумма OFFSETи FETCH), механизм выполнения может использовать другой алгоритм сортировки, который может работать быстрее, чем обобщенная сортировка TopN. Все три случая имеют разные характеристики производительности в целом.

Относительно того, почему оптимизатор не преобразует автоматически используемый ROW_NUMBERсинтаксический шаблон OFFSET, существует ряд причин:

1. Почти невозможно написать преобразование, которое бы соответствовало всем существующим применениям.
2. Автоматическое преобразование некоторых пейджинговых запросов, а другие - не сбивает с толку.
3. OFFSETПлан не гарантированно будет лучше во всех случаях

Один пример для третьего пункта выше встречается, когда набор страниц достаточно широк. Гораздо эффективнее искать ключи, необходимые с использованием некластеризованного индекса и поиска вручную по кластерному индексу, по сравнению со сканированием индекса с помощью OFFSETили ROW_NUMBER. Существуют и другие проблемы, которые необходимо учитывать, если приложению подкачки нужно знать, сколько всего строк или страниц. Существует еще одна хорошая дискуссия относительных достоинств «ключ искать» и «смещение» методы здесь .

В целом, вероятно, лучше, чтобы люди приняли информированное решение изменить свои пейджинговые запросы для использования OFFSET, если это уместно, после тщательного тестирования.

С небольшим изменением вашего запроса я получаю равную оценку стоимости (50/50) и равную статистику ввода-вывода:

; WITH cte AS
(
    SELECT *, ROW_NUMBER() OVER (ORDER BY object_id) r
    FROM #objects
)
SELECT *
FROM cte
WHERE r >= 30 AND r < 40
ORDER BY r

SELECT *
FROM #objects
ORDER BY object_id
OFFSET 30 ROWS FETCH NEXT 10 ROWS ONLY

Это позволяет избежать дополнительной сортировки, которая появляется в вашей версии, сортируя rвместо object_id.

Они изменили оптимизатор запросов для добавления этой функции. Это означает, что они реализовали механизмы специально для поддержки команды offset ... fetch. Другими словами, для верхнего запроса SQL Server должен выполнять гораздо больше работы. Таким образом, разница в планах запросов.