Кластерный индекс

Question

Правда ли, что обновление SQL-запроса происходит медленно из-за кластерного индекса ??????

Answer 1

Вам лучше сказать «медленнее», чем «медленно». Когда данные записываются в кластеризованный индекс, и они не попадают в самый конец таблицы, данные должны быть перемещены, чтобы соответствовать им, так же, как при добавлении компакт-диска в большой стек в алфавитном порядке CD намного медленнее, чем просто вставлять его сверху.

Answer 2

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

Будет ли кластеризованный индекс замедлять INSERT с или нет, зависит от:

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

• Какие столбцы выбраны в качестве ключа кластера.

Если вы используете столбец идентификаторов в качестве ключа кластера, то вы можете обнаружить, что производительность вставки совершенно нормальная, поскольку новые записи всегда добавляются в конце. То же самое может применяться к столбцу datetime, если используется текущая дата (которая, конечно, также продолжает увеличиваться).

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

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

Answer 3

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

Вы можете смягчить проблему, установив соответствующий коэффициент заполнения для ваших индексов. Это не так уж и плохо, что вам нужно заново перевернуть всю таблицу, когда вы добавляете запись в середину; обычно это всего несколько страниц. Fillfactor определяет, сколько каждой страницы заполнено перед созданием новой страницы, и сколько оставить в качестве места для маневра для новых вставок. Более низкий коэффициент заполнения в индексе оставит больше места для новых записей и, следовательно, даст в среднем более быстрое время вставки, за счет увеличения дискового пространства и большего количества страниц и, следовательно, более медленного чтения. Но если вы делаете намного больше обновлений, чем читаете, это может стоить.

Answer 4

Определите медленно, конечно, кластеризованный индекс всегда будет медленнее, чем некластеризованный индекс ...

Answer 5

Вставка и обновления медленнее из-за кластеризованных индексов (особенно в огромных таблицах) - но выбор намного быстрее.

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