SQL-Ex blog

Ах, поиск по индексу - ничего не может быть лучше, правильно?

Ну, не совсем. Давайте внесем небольшое изменение в предложение WHERE, и поищем всех тех людей, кто заходил на Stack Overflow с самого начала:

SELECT Id

  FROM dbo.Users

  WHERE LastAccessDate > '1800-01-01';

Мы по-прежнему получаем "поиск" по индексу:


Да, это поиск, даже если читается почти каждая строка в индексе. Вы, вероятно, думали, что тут должен быть скан, но нет.

Поиск по индексу не обязательно легкая операция.

Поиск по индексу означает лишь то, что SQL Server собирается прыгнуть в конкретное место индекса и начать чтение.

Это не имеет абсолютно никакого отношения к тому, много или мало строк вы собираетесь прочитать. Вы можете выполнить поиск по индексу и прочитать только одну строку, или же прочитать все строки в таблице.

Если вы рассматривали план выполнения и приговаривали "поиск-поиск-поиск, здесь одни поиски, ничего лучше быть не может", то вы упустили что-то довольно крупное.

Сканирование индекса также не означает чтение всей таблицы.

Давайте получим 10 любых пользователей:

SELECT TOP 10 * FROM dbo.Users;

Мы получили сканирование кластеризованного индекса - т.е. читается вся таблица, верно?


Нет - SQL Server начинает сканировать таблицу, но может прекратить, как только найдет достаточно строк, чтобы отправить вам результаты. Наведите мышь на значок сканирования кластеризованного индекса, и он скажет: "Число чтений строк: 10". Если число прочитанных строк равно числу строк на выходе вашего запроса, это замечательно! Я, вероятно, не смогу построить лучший индекс для поддержки такого запроса. Сканирование кластеризованного индекса здесь абсолютно лучший вариант.

Вот что поиск и сканирование на самом деле означают:

• Index seek (поиск): "Я собираюсь прыгнуть в конкретное место и начать чтение".


• Index scan (сканирование): "Я собираюсь перейти в начало или конец таблицы и начать чтение".

А вот чего это не означает:

• Сколько строк мы собираемся прочитать.


• Ищем мы по всем столбцам индекса, или же только по первому (об этом поговорим позже).


• Хороший это индекс или плохой для данного запроса.

Вы не можете делать заключения об индексах, основываясь исключительно на поиске или сканировании. Это особенно справедливо, когда вы начинаете смотреть метрики использования индексов с помощью инструментов типа sp_BlitzIndex: мы просто сообщаем, как осуществляется доступ к индексу. Вы не можете сказать "Этот индекс используется в поиске, поэтому он идеален", как и не можете сказать "Этот индекс сканируется, поэтому ключи должно быть имеют неправильный порядок". Вы должны заглянуть глубже, чтобы увидеть, насколько много данных перемещается - и это не то, что отслеживает DMV. Вам следует внимательней рассмотреть план запроса, чтобы расшифровать что происходит.

Далее, давайте добавим несколько столбцов к нашему запросу, и заставим SQL Server принять непростое решение.