Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Quelles sont les bonnes pratiques pour utiliser un GUID comme clé primaire, notamment en ce qui concerne les performances ?

ayi

ayi_2

Les GUID peuvent sembler être un choix naturel pour votre clé primaire - et si vous y êtes vraiment obligé, vous pourriez probablement justifier de l’utiliser pour la CLÉ PRIMAIRE de la table. Ce que je recommanderais fortement de ne pas faire, c’est d’utiliser la colonne GUID comme clé de clustering, ce que SQL Server fait par défaut, à moins que vous ne lui indiquiez spécifiquement de ne pas le faire.
Vous devez vraiment distinguer deux aspects :
<ul>
<li></li>
</ul>
la clé primaire est un concept logique - l’une des clés candidates qui identifie de manière unique et fiable chaque ligne de votre table. Cela peut être n’importe quoi, vraiment - un <code>INT</code>, un <code>GUID</code>, une chaîne - choisissez ce qui a le plus de sens pour votre scénario.
<ul>
<li></li>
</ul>
la clé de clustering (la ou les colonnes qui définissent “l’index cluster” sur la table) - c’est une question de stockage physique, et ici, un type de données petit, stable et toujours croissant est votre meilleur choix - <code>INT</code> ou <code>BIGINT</code> comme option par défaut.
Par défaut, la clé primaire d’une table SQL Server est également utilisée comme clé de clustering - mais cela ne doit pas nécessairement être le cas ! J’ai personnellement constaté des gains de performance massifs en séparant l’ancienne clé primaire/cluster basée sur un GUID en deux clés distinctes - la clé primaire (logique) sur le GUID, et la clé de clustering (d’ordonnancement) sur une colonne <code>INT IDENTITY(1,1)</code> séparée.
Comme <a href="https://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-the-clustering-key/">Kimberly Tripp</a> - la Reine de l’Indexation - et d’autres l’ont affirmé à de très nombreuses reprises - un <code>GUID</code> comme clé de clustering n’est pas optimal, car en raison de son caractère aléatoire, il entraînera une fragmentation massive des pages et de l’index et des performances généralement médiocres.
Oui, je sais - il y a <code>newsequentialid()</code> dans SQL Server 2005 et versions ultérieures - mais même cela n’est pas véritablement et entièrement séquentiel et souffre donc des mêmes problèmes que le <code>GUID</code> - juste de manière un peu moins prononcée.
Il y a ensuite un autre aspect à considérer : la clé de clustering d’une table sera ajoutée à chaque entrée de chaque index non cluster de votre table - vous voulez donc vraiment la rendre
(Réponse tronquée)