На данный момент у нас есть несколько таблиц, которые используют newid () для первичного ключа. Это вызывает большие количества фрагментации. Поэтому я хотел бы изменить столбец для использования newsequentialid ().
Я полагаю, что существующие данные останутся довольно фрагментированными, но новые данные будут менее фрагментированными. Это означало бы, что я должен подождать некоторое время, прежде чем изменять индекс PK от некластеризованного до кластеризованного.
Мой вопрос: есть ли у кого-нибудь опыт? Есть ли что-то, что я забыл, что я должен быть осторожен?
Если вы переключитесь на последовательные варианты и одновременно переустановите индекс, вы устраните фрагментацию. Я не понимаю, почему вы хотите просто подождать, пока фрагментированные ссылки на страницы не перегруппируются в непрерывных масштабах.
Как вы сказали, вы сделали какие-либо измерения, чтобы показать, что фрагментация действительно влияет на вашу систему? Просто глядя на индекс и видя, что «фрагментирован 75%», не означает, что на него влияет время доступа. Есть много других факторов, которые вступают в игру (ожидаемая продолжительность жизни в буферном пуле, скорость чтения и записи, локальность последовательных операций, параллелизм операций и т. Д. И т. Д.). Хотя переключение с гидов на последовательные концы обычно безопасно, вы можете ввести проблемы еще. Например, вы можете видеть конкуренцию завязки страниц для интенсивной OLTP-системы с вставкой, поскольку она создает страницу с горячей точкой, где накапливаются вставки.
Вы можете подумать об использовании гребенчатых гири , в отличие от newsequentialid.
cast( cast(NewID() as binary(10)) + cast(GetDate() as binary(6)) as uniqueidentifier) Комбинированные гиды представляют собой комбинацию чисто случайных указаний наряду с неслучайностью текущего времени и времени, так что последовательные поколения гребенчатых гидов находятся рядом друг с другом и вообще в порядке возрастания. Комбинированные подсказки имеют различные преимущества перед newsequentialid, в том числе факты, что они не являются черным ящиком, что вы можете использовать эту формулу за пределами ограничения по умолчанию и что вы можете использовать эту формулу вне SQL Server.
Спасибо, yfeldblum! Ваше простое и краткое объяснение GUID COMB действительно помогло мне. Я действительно смотрел на то, чтобы сделать обратное этому сообщению: мне пришлось newsequentialid() от newsequentialid() так как я пытался перенести db SQL Server 2012 в Azure, а newsequentialid() не поддерживается.
Я смог изменить все мои таблицы PK по умолчанию на GUID COMB со следующим синтаксисом:
ALTER TABLE [dbo].[Company] ADD CONSTRAINT [DF__Company__Company_ID__72E6D332] DEFAULT (CONVERT([uniqueidentifier],CONVERT([binary](10),newid(),0)+CONVERT([binary](6),getdate(),0),0)) FOR [CompanyId] GO
Теперь мой SQL2012 db счастливо живет в облаке Azure.
Если это SQL Server, вы генерируете Guid, вызывая newid (). Это не подходит для первичных ключей. Используйте целочисленный столбец идентификатора для первичного ключа и сделайте свой Guid суррогатным ключом (и столбцом строки guid).