Изменение newid() на newsequentialid() по существующей таблице

Question

На данный момент у нас есть несколько таблиц, которые используют newid() для первичного ключа. Это вызывает большие количества фрагментации. Поэтому я хотел бы изменить столбец для использования newsequentialid().

Я предполагаю, что существующие данные останутся довольно фрагментированными, но новые данные будут менее фрагментированными. Это означало бы, что я должен подождать некоторое время, прежде чем изменять индекс PK от некластеризованного до кластеризованного.

Мой вопрос: есть ли у кого-нибудь опыт? Есть ли что-то, что я забыл, что я должен быть осторожен?

Answer 1

Если вы переключитесь на последовательные аргументы и, перестройте индекс один раз в одно и то же время, вы устраните фрагментацию. Я не понимаю, почему вы хотите просто подождать, пока фрагментированные ссылки на страницы не перегруппируются в непрерывных масштабах.

Как вы сказали, вы сделали какие-либо измерения, чтобы показать, что фрагментация на самом деле влияет на вашу систему? Просто глядя на индекс и видя, что «фрагментирован 75%», не подразумевает, что на время доступа влияет. Есть много других факторов, которые вступают в игру (ожидаемая продолжительность жизни в буферном пуле, скорость чтения и записи, локальность последовательных операций, параллелизм операций и т. Д. И т. Д.). Хотя переключение с гидов на последовательные концы обычно безопасно, вы можете ввести проблемы еще. Например, вы можете видеть конкуренцию завязки страниц для интенсивной OLTP-системы с вставкой, поскольку она создает страницу с горячей точкой, где накапливаются вставки.

Answer 2

Если это SQL Server, вы генерируете Guid, вызывая newid(). Это не подходит для первичных ключей. Используйте целочисленный столбец идентификатора для первичного ключа и сделайте свой Guid суррогатным ключом (и столбцом строки guid).

Answer 3

Вы можете подумать об использовании comb guids, в отличие от newsequentialid.

cast(
    cast(NewID() as binary(10)) + 
    cast(GetDate() as binary(6)) 
as uniqueidentifier) 

Comb GUID, представляют собой сочетание чисто случайных GUIDs наряду с неслучайности текущей даты-времени, так что последовательные поколения гребенки GUIDs находятся рядом друг с другом и в целом в порядке возрастания. Комбинированные подсказки имеют различные преимущества перед newsequentialid, в том числе факты, что они не являются черным ящиком, что вы можете использовать эту формулу за пределами ограничения по умолчанию и что вы можете использовать эту формулу вне SQL Server.

Answer 4

Спасибо, yfeldblum! Ваше простое и краткое объяснение GUID COMB действительно помогло мне. Я действительно смотрел на то, чтобы сделать обратное этому сообщению: мне пришлось уйти от того, чтобы полагаться на newsequentialid(), так как я пытался перенести db SQL Server 2012 на Azure, а функция newsequentialid() там не поддерживается.

Я был в состоянии изменить все мои таблицы PK по умолчанию прочесывать GUIDs, со следующим синтаксисом:

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 дб теперь счастливо живет в облаке Azure.