Первичный ключ: медленные вставки?

Question

Определение столбца в качестве основного в таблице на SQL Server - будет ли это делать вставки медленнее?

Я спрашиваю, потому что я понимаю, что это относится к индексам.

Таблица содержит миллионызаписей.

Answer 1

Нет, не обязательно! Звучит нелогично, но прочитайте эту цитату из сообщения Кима Триппа в блоге :

Вставки быстрее в кластере таблица (но только в «правильном» кластерная таблица), чем по сравнению с куча. Основная проблема здесь заключается в том, что поиск в IAM / PFS для определения расположение вставки в куче медленнее, чем в кластерной таблице (где место вставки известно, определяется кластерным ключом). Вставки быстрее, когда вставляются в таблицу где порядок определен (CL) и где этот порядок постоянно увеличивается.

Таким образом, наличие хорошего кластеризованного индекса (например, для столбца INT IDENTITY, если это возможно) ускоряет процесс - даже вставляет, обновляет и удаляет!

Answer 2

Первичные ключи автоматически индексируются, кластеризуются, если это возможно, и при сбое - некластеризованные.

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

Answer 3

Действительно быстрый ответ:

Да.

Первичные ключи всегда индексируются (и SQL будет пытаться кластеризовать индекс). Индексы делают вставки медленнее, а кластеризованные индексы тем более.

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

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

В дополнение к этому вы также можете вставить, используя предложение ORDER BY, которое будет содержать вставленные строки в правильном порядке для кластеризованного индекса. Это действительно поможет, только если вы вставляете миллионы строк одновременно из уже упорядоченного источника.

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Answer 7

Нет, не обязательно

Независимо от этого, вы не определяете первичный ключ для таблицы.

Вы определяете первичный ключ, когда он ТРЕБУЕТСЯ моделью домена.