Идентификаторы 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.Как она показывает в своих «Дебатах о кластеризованном индексе», наличие хорошего ключа кластеризации (в отличие от ни одного или плохого) действительно ускоряет практически все операции с базами данных!Это хорошая идея, но это должен быть хороший ключ кластеризации ....
Марк