Разница в производительности SQL Server с одним или несколькими столбцами первичного ключа?
Есть ли разница в производительности (с точки зрения вставки / обновления и запроса) таблицы, если первичный ключ представляет собой один столбец (например, GUID, сгенерированный для каждой строки) или несколько столбцов (например, GUID внешнего ключа + номер смещения)?
Я бы предположил, что скорость запросов должна быть выше, если что-нибудь с первичными ключами из нескольких столбцов, однако я бы предположил, что вставка будет медленнее из-за немного более сложной уникальной проверки? Я также предполагаю, что типы данных первичного ключа из нескольких столбцов также могут иметь значение (например, если один из столбцов является типом DateTime, это добавит сложности). Это всего лишь мои мысли, чтобы призвать ответы и обсуждения (надеюсь!) И не основаны на фактах.
Я понимаю, что есть некоторые другие вопросы, касающиеся этой темы, но меня интересует влияние на производительность, а не проблемы управления / бизнеса.
4 ответа
На вас больше всего повлияет (каждый) компонент ключа: (а) переменная длина и (б) ширина [широкая, а не узкие столбцы], чем количество компонентов в ключе. Если только MS не сломал его снова в последнем выпуске (они сломали Heaps в 2005 году). Тип данных не замедляет его; ширина и, в частности, переменная длина (любой тип данных). Обратите внимание, что фиксированный столбец len становится переменным, если для него установлено значение Nullable. Переменные длины столбцов в индексах - плохая новость, потому что для получения доступа к данным необходимо выполнять небольшую "распаковку" при каждом доступе.
Очевидно, что индексированные столбцы должны быть как можно более узкими, используя только фиксированные столбцы, а не столбцы Nullable.
С точки зрения количества столбцов в составном ключе, конечно, один столбец быстрее, чем семь, но не так много: три широких переменных столбца значительно медленнее, чем семь тонких фиксированных столбцов.
GUID, конечно, очень жирный ключ; GUID плюс все остальное очень и очень жирно; GUID Nullable - это материал Guiness. К сожалению, это коленная реакция на решение проблемы IDENTITY, которая, в свою очередь, является следствием не выбора хороших естественных реляционных ключей. Поэтому вам лучше всего исправить реальную проблему у источника и выбрать хорошие естественные ключи; избегать ИДЕНТИЧНОСТИ; избегайте GUID.
Опыт и производительность тюнинга, а не домыслы.
Это зависит от ваших шаблонов доступа, отношения чтения / записи и от того, определен ли (возможно, самое главное) кластеризованный индекс в первичном ключе.
Правило большого пальца заключается в том, чтобы сделать ваш первичный ключ как можно меньшим (32-битное целое) и определить кластеризованный индекс по монотонно увеличивающемуся ключу (думаю, IDENTITY), где это возможно, если только у вас нет поисков по диапазону, которые составляют большую часть запросов к этой таблице.,
Если ваше приложение интенсивно пишет, и вы определяете кластерный индекс в столбце GUID, вы должны заметить:
Все некластеризованные индексы будут содержать ключ кластеризованного индекса и поэтому будут больше. Это может оказать негативное влияние на производительность, если имеется много индексов NC.
Если вы не используете "упорядоченный" GUID (например, COMB или NEWSEQUENTIALID()), ваши вставки со временем фрагментируют индекс. Это означает, что вам нужно регулярно перестраивать индекс и, возможно, увеличивать количество свободного места на страницах (коэффициент заполнения)
Поскольку на работе много факторов (аппаратное обеспечение, шаблоны доступа, размер данных), я предлагаю вам провести несколько тестов и сравнить ваши конкретные обстоятельства.
Если ваша ситуация будет ориентирована на большее количество вставок, то чем меньше занимаемая площадь, тем лучше.
Необходимо разделить две вещи: концепцию первичного ключа на уровне базы данных и концепцию ключа, используемого вашим приложением.
Зачем вам нужен GUID? Собираетесь ли вы вставить в несколько серверов базы данных, а затем объединить информацию в одну централизованную базу данных?
Если это так, то моя рекомендация - это личность, за которой следует гид. Кластерный индекс для идентификатора и уникальный не кластеризованный для GUID. Если вы используете GUID в качестве кластерного индекса, то вставка данных будет повсюду. Это означает, что ваши данные не будут вставляться последовательно, и это вызывает проблемы с производительностью, так как ваша система будет вставлять и перемещать страницы случайным образом.
Хорошая вставка данных в упорядоченную фракцию, благодаря идентичности, - это путь. Вы можете оставить сортировку в структуре индекса (непроверенная уникальность, содержащая GUID), которая является намного более эффективной структурой для сортировки, чем использование данных таблицы.
Это зависит от индексации и хранения в каждом конкретном случае. При прочих равных условиях выбор первичного ключа не имеет значения для производительности. Выбор индексов и других вариантов хранения будет решающим фактором.