При какой мощности SQL Server переключается на сканирование индекса (по сравнению с поиском)

Question

Предполагая, что таблица содержит достаточно информации, чтобы гарантировать поиск индекса, при какой мощности SQL Server (или PostgreSQL) выберет сканирование индекса?

Причина, по которой я спрашиваю это, - я ранее разместил вопрос ( ссылка ), в которой два запроса выполнялись с одинаковой скоростью, но один не пытался использовать индекс для обработанных столбцов.После того, как SQL Server предложил добавить индекс покрытия , который включал запрашиваемые столбцы (он предлагал это для обоих запросов), я начал искать причины того, почему это может сделать такое странноепредложение.

Я экспериментировал с созданием индексов, охватывающих и составных, но оба выполнялись в одно и то же время (мы говорим о 3 миллионах строк).

Наконец, я пришел к выводу, что это из-за ультра- высокая мощность данных.Каждый ряд уникален.Я считаю, что это заставило сервер SQL выбрать сканирование индекса.Однако в запросе указано "ГДЕ Col1>? И Col2 <?", Поэтому это немного сбивает с толку. </p>

Мои вопросы:

1. При какой мощности всегда будет выбирать СУБДдля сканирования индекса?
2. Кто-нибудь может объяснить, почему SQL Server не будет использовать индекс, если в выражении WHERE это будет иметь смысл?

Я прикрепил план выполнения.

Answer 1

В терминах SQL Server это упоминается как переломный момент, о котором хорошо известно на блоге Кимберли.http://www.sqlskills.com/BLOGS/KIMBERLY/category/The-Tipping-Point.aspx

Точка перелома - это ориентир в 25% -33% от общего числа страниц в таблице, выраженный в виде строк, например, страницы с данными из 10 тыс. Страниц дают точку перелома в 2500-3333 строк.В соответствии с рекомендациями, это довольно хорошо, и так хорошо, как вы получите - помните, что механизм плана запросов - это черный ящик, и хотя он даст вам план запроса, он только говорит, что он решил, а не почему.

Однако, с точки зрения изменения индекса покрытия, это на самом деле не очень легко, даже при выборе 100% данных индекс покрытия в большинстве случаев все равно будет искать сканирование.

Это имеет смыслЕсли вы считаете, что оптимизатор затрат не назначает никаких реальных затрат иерархии страниц индекса, любой оптимизирует только доступ к конечным страницам индекса.В этот момент сканирование или поиск 100% индекса покрытия стоили одинаково.

Я обнаружил, что в результате моих собственных экспериментов (http://sqlfascination.com/2009/11/07/can-a-covering-nc-index-be-tipped) использование предложения Между заставило бы его сканировать, но другиегде условия не будут - от того, что я мог сказать, это было чисто вниз к маршруту через механизм запросов.

Answer 2

В PostgreSQL это обычно не очень хороший вопрос, потому что фактический выбор плана более сложен.Это зависит от размера таблицы, настроек памяти и других частей запроса.Обычно вы получаете простое индексное сканирование, только если вы выбираете очень мало строк.Кроме того, вы получите сканирование индекса растрового изображения до 40% избирательности в простых экспериментах.