Идентификаторы GUID могут показаться естественным выбором для вашего первичного ключа - и, если вам действительно необходимо, вы, вероятно, можете поспорить, чтобы использовать его для ОСНОВНОГО КЛЮЧА таблицы. я бы настоятельно не рекомендовал использовать столбец GUID в качестве ключа кластеризации , что SQL Server делает по умолчанию, если только вы не указали этого.
Вам действительно нужно держать в стороне две проблемы:
1) первичный ключ - это логическая конструкция - один из ключей-кандидатов, который однозначно и надежно идентифицирует каждую строку в вашей таблице. На самом деле это может быть что угодно - INT, GUID, строка - выберите то, что наиболее подходит для вашего сценария.
2) ключ кластеризации (столбец или столбцы, которые определяют «кластеризованный индекс» в таблице) - это физическая вещь, связанная с хранилищем, и здесь маленький, стабильный, постоянно растущий тип данных - ваш лучший выбор - INT или BIGINT в качестве варианта по умолчанию.
По умолчанию первичный ключ в таблице SQL Server также используется в качестве ключа кластеризации, но это не обязательно должно быть именно так! Я лично наблюдал значительное увеличение производительности, когда разбивал предыдущий первичный / кластерный ключ на основе GUID на два отдельных ключа - первичный (логический) ключ на GUID и ключ кластеризации (упорядочения) на отдельном INT IDENTITY (1, 1) столбец.
Как и Кимберли Трипп - королева индексации - и многие другие неоднократно заявляли - GUID, поскольку ключ кластеризации не является оптимальным, поскольку из-за его случайности он приведет к большому количеству страниц и фрагментация индекса и вообще плохая производительность.
Да, я знаю - в SQL Server 2005 и более поздних версиях newsequentialid() - но даже это не является действительно и полностью последовательным и, следовательно, также страдает от тех же проблем, что и GUID - только чуть менее заметно.
Затем следует рассмотреть еще одну проблему: ключ кластеризации в таблице будет добавлен к каждой записи в каждом и каждом некластеризованном индексе в вашей таблице - таким образом, вы действительно хотите убедиться, что он как можно меньше. , Как правило, INT с 2+ миллиардами строк должно быть достаточно для подавляющего большинства таблиц - и по сравнению с GUID в качестве ключа кластеризации вы можете сэкономить сотни мегабайт хранилища на диске и в памяти сервера.
Быстрый расчет - использование INT и GUID в качестве первичного ключа и ключа кластеризации:
- Базовая таблица с 1 000 000 строк (3,8 МБ против 15,26 МБ)
- 6 некластеризованных индексов (22,89 МБ против 91,55 МБ)
ИТОГО: 25 МБ против 106 МБ - и это только на одном столе!
Еще немного пищи для размышлений - отличный материал Кимберли Триппа - прочитайте его, прочитайте снова, переварите! Это на самом деле индексное Евангелие SQL Server.
Так что если вы действительно должны изменить свои первичные ключи на GUID - попробуйте убедиться, что первичный ключ не является ключом кластеризации, и у вас все еще есть поле INT IDENTITY в таблице, которая используется как ключ кластеризации. В противном случае, ваша производительность обязательно улучшится и получит серьезный удар.