Кластеризованный и некластеризованный индекс в таблице SQL Server

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

Какие-нибудь советы?

Заранее спасибо.


person SQL_M    schedule 24.11.2017    source источник
comment
AFAIK все таблицы в SQL Server имеют кластеризованный индекс, независимо от того, объявляете ли вы его как таковой.   -  person Tim Biegeleisen    schedule 24.11.2017
comment
@TimBiegeleisen: я не думаю, что это правда. Если вы создаете PK как некластеризованный, SQL Server не будет создавать скрытый кластеризованный индекс. Возможно, вы путаете это с MySQL?   -  person a_horse_with_no_name    schedule 24.11.2017
comment
@a_horse_with_no_name По умолчанию SQL Server создает кластеризованный индекс в фоновом режиме (см. здесь). Вы уверены, что это можно отключить, кроме создания другого именованного индекса?   -  person Tim Biegeleisen    schedule 24.11.2017
comment
@TimBiegeleisen create table foo (id integer primary key nonclustered)   -  person a_horse_with_no_name    schedule 24.11.2017
comment
@a_horse_with_no_name Хорошо, но это все равно создает индекс. Я думаю, что я неправильно сформулировал свой первый комментарий.   -  person Tim Biegeleisen    schedule 24.11.2017
comment
Да, но он создает некластеризованный индекс. У вас не может быть первичного ключа без уникального индекса.   -  person a_horse_with_no_name    schedule 24.11.2017
comment
Верно... и ваше предложение может улучшить производительность... Я упустил суть.   -  person Tim Biegeleisen    schedule 24.11.2017


Ответы (1)


Действительно, у кластерных индексов есть и недостатки.

Я думаю, что наиболее недооцененным недостатком является то, что я называю штрафом за кластеризованный индекс.

Если у вас нет какого-либо кластеризованного индекса для таблицы, это означает, что таблица хранится как таблица в куче. Все некластеризованные индексы ссылаются на эту таблицу кучи.

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

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

Если вы в конечном итоге используете некластеризованный индекс, усилия по доступу к фактической таблице в куче или в кластерном индексе сильно различаются: с кучей вам просто нужен один физический ввод-вывод, с кластеризованным индексом вам нужно сделать Кластерный поиск по индексу, который обычно составляет 3–5 логических операций ввода-вывода (в зависимости от размера таблицы).

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

Подробнее об этом в этой статье я писал:

http://use-the-index-luke.com/blog/2014-01/unreasonable-defaults-primary-key-clustering-key

person Markus Winand    schedule 24.11.2017