Разница в производительности SQL Server с одним или несколькими столбцами первичного ключа? - PullRequest
8 голосов
/ 25 октября 2010

Есть ли разница в производительности (с точки зрения вставки / обновления и запроса) таблицы, если первичный ключ представляет собой один столбец (например, GUID, сгенерированный для каждой строки) или несколько столбцов (например, GUID внешнего ключа + номер смещения)?

Я бы предположил, что скорость запросов должна быть выше, если что-нибудь с первичными ключами, состоящими из нескольких столбцов, однако я мог бы предположить, что вставка будет медленнее из-за немного более сложной уникальной проверки? Я также предполагаю, что типы данных первичного ключа из нескольких столбцов также могут иметь значение (например, если бы один из столбцов был типом DateTime, это добавило бы сложности). Это всего лишь мои мысли, чтобы вызвать ответы и обсуждение (надеюсь!), И они не основаны на фактах.

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

Ответы [ 4 ]

4 голосов
/ 26 октября 2010

На вас больше влияет (каждый) компонент ключа (а) переменная длина и (б) ширина [широкая, а не узкие столбцы], чем количество компонентов в ключе. Если только MS не сломал его снова в последнем выпуске (они сломали Heaps в 2005 году). Тип данных не замедляет его; ширина и, в частности, переменная длина (любой тип данных). Обратите внимание, что фиксированный столбец len становится переменным, если для него установлено значение Nullable. Переменные len столбцов в индексах - это плохие новости, потому что при каждом доступе нужно выполнять небольшую «распаковку», чтобы получить данные.

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

С точки зрения количества столбцов в составном ключе, конечно, один столбец быстрее, чем семь, но не так много: три широких переменных-столбца намного медленнее, чем семь тонких фиксированных столбцов.

GUID, конечно, очень жирный ключ; GUID плюс все остальное очень и очень жирно; GUID Nullable - это материал Guiness. К сожалению, это коленная реакция на решение проблемы IDENTITY, которая, в свою очередь, является следствием того, что не были выбраны хорошие естественные реляционные ключи. Поэтому вам лучше всего исправить реальную проблему в источнике и выбрать хорошие естественные ключи; избегать ИДЕНТИЧНОСТИ; избегайте GUID.

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

1 голос
/ 25 октября 2010

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

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

Если ваше приложение интенсивно пишет, и вы определяете кластеризованный индекс в столбце GUID, вы должны отметить:

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

  2. Если вы не используете "заказанный" GUID (например, COMB или использование NEWSEQUENTIALID ()), ваши вкладыши будет фрагментировать индекс с течением времени. Это означает вам нужна регулярная перестройка индекса и возможно увеличение количества на страницах осталось свободное место (заполните фактор)

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

0 голосов
/ 15 июля 2014

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

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

Зачем вам нужен GUID?Собираетесь ли вы вставлять данные на несколько серверов баз данных, а затем объединять информацию в одну централизованную базу данных?

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

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

0 голосов
/ 25 октября 2010

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

...