Вопреки тому, что большинство людей здесь, кажется, проповедуют, я считаю, что GUID скорее чума, чем благословение. И вот почему:
Идентификаторы GUID могут показаться естественным выбором для вашего первичного ключа - и, если вам действительно нужно, вы, вероятно, можете поспорить, что он будет использоваться для ПЕРВИЧНОГО КЛЮЧА таблицы. Я бы настоятельно рекомендовал не делать , а использовать столбец GUID в качестве ключа кластеризации , что SQL Server делает по умолчанию, если вы специально не запретите.
Вам действительно нужно держать в стороне две проблемы:
первичный ключ - это логическая конструкция - один из ключей-кандидатов, который уникально и надежно идентифицирует каждую строку в вашей таблице. Это может быть что угодно, на самом деле - INT, GUID, строка - выберите то, что наиболее подходит для вашего сценария.
ключ кластеризации (столбец или столбцы, которые определяют «кластеризованный индекс» в таблице) - это физическая вещь, связанная с хранилищем, и здесь, маленький, стабильный, постоянно растущий тип данных - ваш лучший выбор - 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.
Марк