SQL GUID против целого

INT

Преимущество:

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

Недостаток:

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

GUID

Преимущество:

Уникальность по всему серверу.

Недостаток:

Строковые значения не так оптимальны по производительности, как целочисленные, при использовании в соединениях, индексах и условиях. Требуется больше места для хранения, чем INT.

кредит отправляется на : http://blog.sqlauthority.com/2010/04/28/sql-server-guid-vs-int-your-opinion/

Вопреки тому, что, кажется, проповедует большинство людей, я считаю GUID скорее чумой, чем благословением. Вот почему:

GUID могут показаться естественным выбором для вашего первичного ключа - и, если вы действительно должны, вы, вероятно, можете поспорить, использовать его для ПЕРВИЧНОГО КЛЮЧА таблицы. Я настоятельно рекомендую не делать , так это использовать столбец GUID в качестве ключа кластеризации , что SQL Server делает по умолчанию, если вы специально не укажете ему этого не делать.

Вам действительно нужно разделить две проблемы:

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

2. ключ кластеризации (столбец или столбцы, которые определяют «кластеризованный индекс» в таблице) - это физический элемент, связанный с хранилищем, и здесь небольшой, стабильный, постоянно увеличивающийся тип данных - ваш лучший выбор - INT или BIGINT по умолчанию.

По умолчанию первичный ключ в таблице SQL Server также используется в качестве ключа кластеризации, но так быть не должно! Я лично видел значительный прирост производительности при разделении предыдущего первичного / кластерного ключа на основе GUID на два отдельных ключа - первичный (логический) ключ в GUID и ключ кластеризации (упорядочивания) в отдельном INT IDENTITY (1, 1) столбец.

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

Да, я знаю - в SQL Server 2005 и новее есть newsequentialid () , но даже он не является полностью последовательным и, следовательно, страдает теми же проблемами, что и GUID, только немного меньше заметно так. Кроме того, вы можете использовать его только по умолчанию для столбца в своей таблице - вы не можете получить новый последовательный GUID в коде T-SQL (например, триггер или что-то в этом роде) - еще один серьезный недостаток.

Тогда есть еще одна проблема, которую следует учитывать: ключ кластеризации в таблице будет добавлен к каждой записи в каждом некластеризованном индексе в вашей таблице, поэтому вы действительно хотите, чтобы он был как можно меньше. . Как правило, INT с 2+ миллиардами строк должно быть достаточно для подавляющего большинства таблиц - и по сравнению с GUID в качестве ключа кластеризации вы можете сэкономить сотни мегабайт хранилища на диске и в памяти сервера.

Быстрый расчет - использование INT и GUID в качестве первичного и кластерного ключа:

• Базовая таблица с 1 000 000 строк (3,8 МБ против 15,26 МБ)
• 6 некластеризованных индексов (22,89 МБ против 91,55 МБ )

ИТОГО: 25 МБ против 106 МБ - и это только на одной таблице!

Еще немного пищи для размышлений - отличный материал Кимберли Трипп - прочтите, прочтите еще раз, усвойте! На самом деле это евангелие индексации SQL Server.

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

Марк

Существует тонна статей об использовании GUID в качестве PK, и почти все они говорят то же самое, что говорит ваш подрядчик DBA - запросы выполняются быстрее без GUID в качестве ключей.

Основное применение, которое я видел на практике (мы никогда не использовали их в качестве PK) - это репликация. На странице MSDN для uniqueidentifier говорится примерно то же самое.

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

По сути, они избавляют вас от иногда более сложной логики использования

set @InsertID = scope_identity()