Уникальный идентификатор (guid) как первичный ключ в дизайне базы данных

Question

Наши данные находятся в базе данных SQL Server 2008, будет много запросов и объединений между таблицами. У нас есть этот аргумент внутри команды, некоторые утверждают, что использование целочисленной идентичности лучше для производительности, некоторые утверждают использование guid (уникальный идентификатор).

Неужели производительность сильно страдает от использования GUID в качестве первичного ключа?

Answer 1

128-битный ключ GUID (uniqueidentifier), конечно, в 4 раза больше, чем 32-битный int ключ. Тем не менее, есть несколько ключевых преимуществ:

• При объединении контента не возникает проблема «IDENTITY INSERT»
• Если вы используете значение COMB вместо NEWSEQUENTIALID (), вы получите «бесплатную» метку времени INSERT. Вы можете даже SELECT из первичного ключа на основе диапазона даты / времени, если хотите сделать несколько необычных CAST() вызовов.
• Они уникальны во всем мире, что время от времени оказывается очень удобным.
• Поскольку нет необходимости отслеживать верхние отметки, ваш уровень BL может назначать значение, а не SQL Server, что исключает шаг SELECT scope_identity() для получения первичного ключа после вставки.
• Если даже удаленно возможно, что у вас может быть более 2 миллиардов записей, вам нужно будет использовать bigint (64 бита) вместо int. Как только вы это сделаете, uniqueidentifier только в два раза больше, чем bigint.
• Использование идентификаторов GUID делает более безопасным раскрытие ключей в URL-адресах и т. Д., Не подвергая себя атакам «угадывания идентификатора».
• Между тем, как SQL Server загружает страницы с диска, и тем, что процессоры теперь в основном 64-разрядные, то, что число составляет 128 бит вместо 32, не означает, что для сравнения требуется в 4 раза больше времени. Последний тест, который я видел, показал, что GUID почти такие же быстрые.
• Размер индекса зависит от количества столбцов. Даже если сами GUID больше, дополнительные 8 или 12 байтов могут быть незначительными по сравнению с другими столбцами в индексе.

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

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

Answer 2

Лично я использую INT IDENTITY для большинства моих первичных и кластерных ключей.

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

ключ кластеризации в SQL Serverфизическая конструкция используется для физического упорядочения данных, и ее намного сложнее понять.Как правило, королева индексирования на SQL Server, Кимберли Трипп, также требует, чтобы хороший ключ кластеризации был уникальным, стабильным, как можно более узким и идеально постоянно увеличивающимся (все из которых INT IDENTITY).

См. Ее статьи по индексированию здесь:

• GUID в качестве ПЕРВИЧНЫХ КЛЮЧЕЙ и / или ключа кластеризации
• Дебаты о кластеризованных индексах продолжаются ...
• Постоянно увеличивающийся ключ кластеризации - дебаты по кластерному индексу .......... снова!

, а также см.Джимми Нильссон Стоимость GUID в качестве первичного ключа

GUID - ужасно плохой выбор для ключа кластеризации, так как он широкий, абсолютно случайный и, следовательно, приводит к плохой фрагментации индекса и низкой производительности,Кроме того, строки ключей кластеризации также хранятся в каждой записи каждого некластеризованного (дополнительного) индекса, так что вы действительно хотите сохранить его небольшим - GUID равен 16 байтам, тогда как INT равен 4 байтам, ис несколькими некластеризованными индексами и несколькими миллионами строк это делает ОГРОМНОЕ различие.

В SQL Server ваш первичный ключ по умолчанию является вашим ключом кластеризации, но это не обязательно.Вы можете легко использовать GUID в качестве первичного ключа, не относящегося к кластеру, и INT IDENTITY в качестве ключа кластеризации - вам просто нужно знать об этом.

Answer 3

Отличная статья об этом, которая есть в моих закладках: http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/guid-vs-int-debate.aspx

Answer 4

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

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

Разница в размерах меня не сильно беспокоит, за исключением таблиц с в противном случае узкими строками, где также требуется сканирование таблиц. В этих случаях возможность размещения большего количества строк на странице БД является преимуществом производительности.

Могут быть веские причины для использования GUID, но есть и стоимость. Я обычно предпочитаю INT IDENTITY для первичных ключей, но я не избегаю GUID, когда они являются лучшим решением.

Answer 5

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

Answer 6

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

Основным недостатком использования идентификаторов GUID в качестве значений ключей является то, что они BIG. По 16 байт, они являются одним из крупнейших типов данных в SQL Сервер. Индексы, основанные на GUID, будут больше и медленнее, чем индексы, построенные на столбцах IDENTITY, обычно это целые числа (4 байта).

Таким образом, они являются хорошим решением для случаев, когда вам необходимо объединить данные из нескольких источников

Источник: http://www.sqlteam.com/article/uniqueidentifier-vs-identity