Почему / когда / как выбирается сканирование всего кластерного индекса, а не полное сканирование таблицы?

Question

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

Как кластерный индекс для столбца CUSTOMER_ID используется в запросе SELECT, который не содержится ни в списке SELECT, ни в условии WHERE [1]?

Обновление:
Должен ли я понимать, что полное кластерное сканирование быстрее, чем полное сканирование таблицы, потому что «Каждая страница данных содержит указатели на следующую и предыдущую страницу конечного узла, поэтому при сканировании не нужно использовать страницы более высокого уровня в индексе»?
Существуют ли другие причины, по которым (не участвуя в запросе) кластерный индекс используется при сортировке?

Обновление 2:
Как и следовало ожидать, последовательный доступ не может повысить производительность, а загрузка таблицы через указатели IAM может быть распараллелена.
Предполагает ли сканирование кластерного индекса последовательное чтение страниц?
Означает ли кластеризованная таблица отсутствие указателей IAM (невозможность полного сканирования таблицы)?
Почему кластеризованная таблица не может быть отсканирована с полной таблицей?
Я все еще не понимаю, как / почему полное сканирование кластерного индекса может быть "лучше" по сравнению сполное сканирование таблицы.
Означает ли это, что кластеризованный индекс может привести к снижению производительности?

Вопрос касается кластеризованной таблицы, а не таблицы кучи (неиндексированной).

Update3:
Является ли «полное сканирование кластеризованного индекса» действительно синонимом «полного сканирования таблицы»?
В чем различия?

[1] Покрытие индекса повышает производительность запросов SQL Server
http://www.devx.com/dbzone/Article/29530

Answer 1

Конечный уровень кластеризованного индекса - таблица. «Сканирование таблицы» относится к куче без кластерного индекса.

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

Answer 2

Кластерный индекс - или, точнее: его конечные страницы ARE данные таблицы - поэтому сканирование кластерного индекса действительно такое же, как сканирование таблицы (для таблицы с кластерным индексом).

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

Answer 3

Пожалуйста, прочитайте мой ответ под «Нет прямого доступа к строке данных в кластеризованной таблице - почему?» , сначала.

"лист кластеризованного индекса содержит строку реальной таблицы, поэтому полный кластеризованный индекс с промежуточными листьями содержит намного больше данных, чем полная таблица (?)"

Видите, вы смешиваете "Стол" со структурами хранения. В контексте вашего вопроса, например. Если подумать о размере КИ, а не о «таблице», то вы должны подумать о КИ за вычетом уровня листа (который является строкой данных). КИ, только индексная часть, крошечная. Промежуточные уровни (как и любое B-дерево) содержат частичные (не полные) ключевые записи; он исключает самый низкий уровень, который представляет собой запись полного ключа, которая находится в самой строке и не дублируется.

Таблица (полный CI) может быть 10 ГБ. Только CI может быть 10 МБ. Из 10 МБ можно определить очень много, не обращаясь к 100 ГБ.

Для понимания: эквивалентный NCI в той же таблице (CI) может составлять 22 МБ; эквивалентный NCI в той же таблице, если вы удалили CI, может составлять 21,5 МБ (при условии, что ключ CI является разумным, а не широким).

«Почему / когда / как всегда выбирается сканирование всего кластерного индекса по сравнению с полным сканированием таблицы?»

Довольно часто. Опять же, контекст, мы говорим об уровнях CI-minus-Leaf. Для запросов, которые используют только столбцы в CI, наличие этих столбцов в CI (фактически, любой индекс) позволяет запросу быть «покрытым запросом», что означает, что он может полностью обслуживаться из индекса, нет необходимости переходить к строкам данных. Думайте диапазон сканирования на частичные ключи: между x и yy; х <= у; и т.д. </p>

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

«Я до сих пор не понимаю, как / почему полное сканирование кластерного индекса может быть« лучше »по сравнению с полным сканированием таблицы».

(Термины, используемые MS, являются менее точными, чем мои ответы здесь.) Для любого запроса, на который можно ответить из 10 МБ CI, я бы предпочел использовать 10 МБ через кеш данных, чем 100 ГБ. Для тех же запросов, ограниченных диапазоном ключа CI, это доля от 10 МБ.

Для запросов, требующих "полного сканирования таблицы", ну, да, вы должны прочитать все листовые страницы CI, которые составляют 100 ГБ.