Разница между поиском кластеризованного индекса и поиском некластеризованного индекса

В чем разница между поиском по кластерному индексу (CI) и поиском по некластерному индексу (NCI)? Один работает лучше, чем другой?

Я спрашиваю об этом потому, что у меня есть таблица с 50 миллионами строк и 150 столбцами. У него есть столбец с именем, IDопределенным как кластерный индекс. На нем есть еще один NCI с тем же идентификатором ключа индекса и семью includeстолбцами. Мне кажется, что индекс NC здесь является дубликатом и может быть безопасно удален.

Поэтому я хочу получить несколько экспертных мнений / советов о том, можно ли их безопасно отбросить или следует сохранить их нетронутыми?

sql-server sql-server-2012 index-tuning

— SQLPRODDBA
источник

Вы говорите, что ВСЕ столбцы включены в не кластерный индекс?

— Ян Рингроз

Нет. Таблица содержит 150 столбцов с идентификатором столбца, определенным как CI, и имеет индекс NCI с снова идентификатором столбца в качестве ключа индекса и еще 7 включенными столбцами.

— SQLPRODDBA

Тогда Пол Уайт, кажется, дал правильный ответ, однако я спрашиваю, стоит ли вам менять «базовую» таблицу с кластерной таблицы на кучу. Или даже разбить таблицу в зависимости от того, как часто обновляются разные столбцы, чтобы снизить затраты на ведение журнала транзакций.

— Ян Рингроз

Некластеризованный индекс, имеющий тот же ключ (и) *, что и кластеризованный индекс, все еще может быть полезен, поскольку некластеризованный индекс обычно будет меньше и плотнее. Помните, что кластерный индекс включает в себя все данные в строке, поэтому обычно это самый широкий (наименее плотный) индекс.

_{* Одни и те же ключевые столбцы в одинаковой последовательности сортируются одинаково (asc / desc).}

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

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

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

— Пол Уайт 9
источник