Если вы можете, я бы порекомендовал следующее:
удалить существующий первичный ключ - особенно если это тоже ключ кластеризации (по умолчанию)
добавить новый INT IDENTITY
столбец
ALTER TABLE dbo.YourTable ADD NewID INT IDENTITY(1,1)
сделать это поле INT первичным / кластерным ключом:
ALTER TABLE dbo.YourTable
ADD CONSTRAINT PK_YourTable PRIMARY KEY(NewID)
Первичный ключ (или точнее: ключ кластеризации ) в столбце GUID - ужасная идея, приводящая к массовой фрагментации индекса и, таким образом, убивающая производительность SELECT.
Как и Кимберли Трипп - королева индексации - и другие много раз заявляли - 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.