MS SQL Server
  1. MS SQL Server
  3. GUID séquentiel à bigint
Intereting Posts
Conception de table Sql – Choix de la key primaire à partir d'une key unique par rapport à la key d'entreprise SQL select le nombre dynamic d'loggings SELECT COL1 + COL2 comme CalcColumn, * FROM TABLE WITH (NOLOCK) O 100 100 <COL1 + COL2 T SQL CHECK Contrainte pour autoriser l'set de valeurs majuscules Y at-il de toute façon pour réinitialiser l'identité d'une variable de table? Python – Utilisation de pyodbc pour se connecter au server distant en utilisant les informations de la connection de données Excel Comment puis-je afficher une image à partir de SQL Server en utilisant ASP.NET? Essayer de capturer le résultat d'une requête select dans une variable mais en obtenant des erreurs de syntaxe Comment append une base de colonne de numéro de ligne sur des loggings dupliqués qui ont été commandés RData prend plus de time à charger que d'interroger la database Rappeler le cas enregistré dans TSQL Impossible de find l'object car il n'existe pas ou vous n'avez pas d'permissions, erreur dans SQL Server Agrégation et ligne dupliquée avec une jointure à gauche T-SQL Conversion d'un FLOAT en INT Lignes multiplicatives SQL. Les données de la même table l'une à côté de l'autre dans select

GUID séquentiel à bigint

Je supervise actuellement une database qui a des GUID (séquentiels) partout. Cette database va grossir considérablement à court terme. Ce ne serait pas trop de travail pour convertir tout le shebang pour utiliser bigint. Je me request, est-ce que ça vaut le coup?

Les index clusterisés vont s'effondrer à mesure que la taille augmente, la taille des pages SQL va augmenter, j'attends toutes sortes d'enfer si je continue sur le path en utilisant des GUID séquentiels. Des pages fragmentées, une indexing effroyable … (surtout en cas de redémarrage du server, ce qui réinitialise la création du GUID séquentiel)

Y a-t-il un monde dans lequel je pourrais garder le GUID pour quelque raison et utiliser bigint pour l'indexing? Toutes les instructions SQL peuvent facilement être converties pour utiliser une colonne bigint pour les clauses SELECT.

Quelle est ma meilleure approche? Une raison de garder les GUID autour? Ou devrais-je simplement tout convertir en bigint et courir à partir de là?

@simon_j_dm: Les GUID séquentiels ne sont pas classés comme BIGINT … Seq. GUID vous donne 1000 longues séquences de GUID ordonnés … mais entre ces séquences … vous voyez toujours la fragmentation.

BIGINT est le type de key le plus ordonné que vous pouvez avoir.

Est-ce que cela signifie que vous devriez changer? pas nécessairement, BIGINT sont plus petits, donc vous avez less de pression de memory, et ils ne provoquent pas de fragmentation comme le fait les GUID. Mais en fonction de la charge, vous pourriez voir la congestion de locking utilisera BIGINT, que vous ne verrez pas sur les GUID comme ils par nature répartir la charge sur plus de pages.

Vous pouvez réduire la fragmentation avec les GUID en réduisant le facteur de remplissage. Cela provoque cependant la database à gonfler en taille MB, et vous ne remplissez pas les pages de données tout de suite. Et vous aurez toujours besoin de faire face à la fragmentation à un moment donné.

Donc, mon point est … vous devez faire ce qui est bon pour votre situation. Il n'y a pas de moyen en or de le faire. Faites le path Brent Ozar:

  1. Déterminez ce que vous voulez changer.
  2. Testez votre changement dans un environnement contrôlé
  3. Messure si le changement a eu l'effet désiré.

Si vous utilisez des guid séquentiels, ils sont commandés comme un bigint. Passer à un bigint n'affecte en rien la fragmentation. Le passage à un bigint réduirait cependant l'espace de stockage de 50% sur ces colonnes, ce qui réduirait également l'utilisation de la memory et les performances générales des requêtes, car les allocations de memory peuvent être plus faibles et l'utilisation de tempdb réduite. Si ce n'est pas trop de douleur, je le changerais car les types de données plus petits sont toujours préférés.