Автор:
Hugo Kornelis,
Storage structures 1 – On-disk rowstore;
Когда запрос выполняется медленно, это часто вызвано неэффективным доступом к данным. Поэтому наша работа по настройке очень часто сводится к выяснению того, как были прочитаны данные, и затем к корректировке наших запросов или структур базы данных, чтобы заставить SQL Server обращаться к данным более эффективным способом.
Итак, мы рассматриваем просмотры (scans), поиски (seeks) и обратные поиски (lookups). Мы знаем, что просмотры хороши, когда мы обращаемся к большей части данных. Или, в случае упорядоченного просмотра, чтобы избежать необходимости сортировки данных. Мы знаем, что поиск предпочтительнее, когда в запросе есть фильтр. И мы знаем, что обратный поиск представляет собой хороший компромисс между лучшей производительностью и слишком большим количеством индексов, но только если фильтр высокоизбирательный.
Всё вышесказанное верно. И всё это очень обобщённо. И, следовательно, часто недостаточно верно, чтобы быть действительно полезным.
SQL Server за годы своего развития научился поддерживать ошеломляющее количество различных структур хранения. Мы все знаем о кучах (heaps), а также о кластерных и некластерных B-деревьях (индексах). Но есть гораздо больше. Columnstore-индексы. Индексы, оптимизированные для памяти. Специализированные структуры индексов для поддержки определённых типов данных, таких как XML, JSON или векторы. И многое другое.
На высоком уровне общие описания просмотров, поисков и обратных поисков всегда применимы. Но вы по-настоящему поймёте влияние каждого из этих операторов на конкретный объект хранения, только если будете знать тип структуры хранения... и знать детали реализации этой структуры хранения.
Это первая из серии статей в блоге, в которых я планирую описать все структуры хранения, которые в настоящее время поддерживает SQL Server, и объяснить, как это влияет на просмотры, поиски и обратные поиски.
Для некоторых из вас это, возможно, уже знакомо. Но хорошее повторение никогда не помешает! Для других всё это может быть новым. Надеюсь, это поможет вам лучше понять, что происходит в планах выполнения ваших плохо ведущих себя запросов!
