Как TOP влияет на производительность SQL

Question

Я немного растерялся. У меня есть два почти идентичных запроса:

select
    top 301
    *
from
    view
where
    columnA like '%val%'
    and
    columnB > '12/12/2019 00:00:00'
order by
    columnC

и

select
    *
from
    view
where
    columnA like '%val%'
    and
    columnB > '12/12/2019 00:00:00'
order by
    columnC

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

Я выполнил некоторые попытки устранения неполадок, и кажется, что для истечения времени ожидания приложения должно быть следующее .

1. top # должен быть включен
2. упорядочить по должен быть на columnC
3. columnB должно быть достаточно далеко в прошлом.

Из-за того, как настроено мое приложение, настройка для запроса всегда будет включать эти три элемента, и я не могу переместить ни один из этих элементов в само представление, поэтому они всегда будут полной таблицей сканирует.

Я пытаюсь оптимизировать свое представление, но я просто не понимаю, как добавление top # к запросу приводит к истечению времени ожидания приложения. Мы будем благодарны за любую помощь в понимании того, как top влияет на производительность SQL.

Дополнительные примечания:

Я заметил, что добавление TOP немного меняет план выполнения. Самое большое различие, которое я вижу в этих двух, состоит в том, что без top план выполнения выполняет параллелизм практически во всех соединениях, и это не относится к запросу, содержащему top.

Answer 1

То, что вы видите в своем плане выполнения, нормально. Если вы проверите документы , то увидите, что есть несколько конструкций, которые запрещают параллелизм:

• скалярные UDF
• удаленный запрос
• dynamici c cursors
• рекурсивные запросы
• Многозначные табличные функции
• TOP ключевое слово

Таким образом, добавление TOP может не выглядеть как что-то big, но в некоторых случаях оно полностью изменит план выполнения.

Иногда, один из способов оптимизировать выполнение представления - это его материализовать. Существует множество ограничений о том, что может существовать в индексированном представлении, но если ваше представление может быть материализовано, вы должны попробовать его.

Answer 2

Если вы пытаетесь показать страницы с ограниченным количеством записей в вашем приложении, я бы посоветовал вам использовать OFFSET Fetch .

1- T- SQL Запрос: TOP и OFFSET-FETCH
Источник: 1