Changer newid() en newsequentialid() sur une table existante

Question

Pour le moment, nous avons un certain nombre de tables qui utilisent newid() sur la clé primaire.Cela provoque une grande fragmentation.Je voudrais donc changer la colonne pour utiliser à la place newsequentialid().

J'imagine que les données existantes resteront assez fragmentées mais les nouvelles données le seront moins.Cela impliquerait que je devrais peut-être attendre un peu avant de changer l'index PK de non clusterisé à clusterisé.

Ma question est la suivante : est-ce que quelqu'un a de l'expérience dans ce domaine ?Y a-t-il quelque chose que j'ai oublié et auquel je devrais faire attention ?

Answer 1

Si vous passez aux guides séquentiels et réorganisez l'index une fois en même temps, vous éliminerez la fragmentation.Je ne comprends pas pourquoi vous voulez simplement attendre que les liens des pages fragmentées se réorganisent de manière continue.

Cela étant dit, avez-vous effectué des mesures démontrant que la fragmentation affecte réellement votre système ?Il suffit de regarder un index et de voir « est fragmenté à 75 % » pas impliquer que le temps d’accès est affecté.De nombreux autres facteurs entrent en jeu (espérance de vie des pages du pool de tampons, taux de lecture par rapport aux pages).écritures, localité des opérations séquentielles, concurrence des opérations etc etc).Bien que le passage des guids aux guids séquentiels soit généralement sûr, vous pouvez quand même introduire des problèmes.Par exemple, vous pouvez voir les conflits de verrouillage de page pour un système OLTP intensif en insertion, car il crée une page de point chaud où les insertions s'accumulent.

Answer 2

Vous pourriez penser à utiliser peigne GUIDs, par opposition à newsequentialid.

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

guids en peigne sont une combinaison de guids purement aléatoires ainsi que le non-aléatoire de la date-heure actuelle, de sorte que les générations séquentielles de GUID en peigne sont proches les uns des autres et en général dans l'ordre croissant. Peigne GUIDs présentent différents avantages par rapport newsequentialid, y compris les faits qu'ils ne sont pas une boîte noire, que vous pouvez utiliser cette formule en dehors d'une contrainte par défaut, et que vous pouvez utiliser cette formule en dehors de SQL Server.

Answer 3

Merci, yfeldblum! Votre explication simple et concise de COMB GUIDs m'a vraiment aidé. Je cherchais en fait à faire l'inverse de ce post: je devais sortir de compter sur newsequentialid() depuis que je suis en train de migrer un SQL Server 2012 db à Azure, et la fonction newsequentialid() est pas pris en charge là-bas.

J'ai pu changer tout de ma table par défaut PK à peigner GUIDs, avec la syntaxe suivante:

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

Mon SQL2012 db vit maintenant avec bonheur dans le nuage Azure.

Answer 4

Si cela est SQL Server, vous générez un Guid en appelant newid (). Ce n'est pas bon pour les clés primaires. Utilisez une colonne d'identité entière pour la clé primaire, et faites votre Guid une clé de substitution (et une colonne de guid ligne).