guid Création d'une clé primaire pour la requête la plus rapide sélectionnez où guid (guid1, guid2, guid3 ...)

Question

Il est nécessaire d'utiliser GUID (s) comme clés primaires. Ai-je raison de penser que

ProductID UNIQUEIDENTIFIER NOT NULL 
ROWGUIDCOL DEFAULT (NEWSEQUNTIALID()) PRIMARY KEY CLUSTERED 

donnera le plus rapide de sélection pour where

productid in (guid1 , guid2 ,..., guidn)

et ne se détériore pas non cluster

natural_key like 'Something*'

select indépendant. Table à interroger uniquement par les utilisateurs et créé/recréé par programmation à partir de zéro.

Answer 1

Un index cluster est le mieux adapté à la gamme des recherches, il pourrait satisfaire votre requête:

productid in (guid1 , guid2 ,..., guidn) 

mais dépend ce que vous sélectionnez, regroupement par, commande par etc si l'indice est d'être une couverture indice. Sinon, un autre index non groupé peut être sélectionné par l'optimiseur suivi d'une recherche dans l'index clusterisé. Cela dépend aussi dans une certaine mesure du nombre de lignes dans cette table.

Aussi, je pense que vous pouvez utiliser NEWID() comme opposer NEWSEQUENTIALID()

Answer 2

Le fait que vous utilisez des années GUID comme un index ordonné en clusters sera très certainement un impact négatif sur votre performance. Même avec le NEWSEQUENTIALGUID, les GUID ne sont pas vraiment séquentiels - ils ne le sont que partiellement. Leur nature aléatoire conduira certainement à une fragmentation de l'indice plus élevée et donc à des temps de recherche moins optimaux. De plus, si vous disposez d'un GUID de 16 octets comme clé en cluster, il sera ajouté à tout index non cluster de cette table. Cela peut ne pas sembler si mauvais, mais si vous avez 10 mio. lignes, 10 index non clusterisés, utilisant un GUID de 16 octets par rapport à un INT de 4 octets vous coûtera 1,2 Go de stockage gaspillé - et pas seulement sur disque (ce qui est bon marché), mais aussi dans la mémoire de votre serveur SQL (depuis Le serveur SQL charge toujours des pages entières de 8 ko dans des blocs de mémoire de 8 ko, qu'ils soient pleins ou vides.

Je peux voir le point d'utiliser un GUID comme une clé primaire - ils sont presque 100% garantie d'être unique est attrayant pour les développeurs. MAIS: comme une clé en cluster, ils sont un cauchemar pour votre base de données.

Ma meilleure pratique: si j'ai vraiment besoin d'un GUID comme clé primaire, j'ajoute une INT INTENTION de 4 octets à la table qui sert alors de clé groupée - les résultats sont bien meilleurs! Si vous disposez d'une clé primaire non groupée, vos requêtes utilisant la liste des GUID seront tout aussi rapides que si vous utilisez une clé primaire en cluster et si vous n'utilisez pas de GUID pour votre clé en cluster, votre table fonctionnera mieux à la fin.

Lisez plus sur la touche en cluster et pourquoi il est si important de choisir le bon dans le blog de Kimberly Tripps - la la reine d'indexation et peut expliquer les choses beaucoup mieux que moi:

• GUIDs as PRIMARY KEY and/or clustered key
• The clustered index debate continues
• Ever-increasing clustering key - the Clustered Index Debate..........again!

Marc

Answer 3

De même que les GUID étant mauvais (réponse de marc_s), vous avez également une clause IN. Cela descend jusqu'à:

productid = guid1 OR productid = guid2 OR ... OR productid = guidn 

... en pratique, ce qui n'est pas optimal non plus.

Généralement, natural_key like 'Something%' sera probablement mieux pour un index clusterisé sur votre colonne de clé natrual.