Dans une table sans index clusterisé (une table de tas), les pages de données ne sont pas liées entre elles - donc la traversée des pages nécessite un recherche dans la carte d'allocation d'index .
Une table en cluster, cependant, a ses pages de données liées dans une liste doublement liée - rendre les analyses séquentielles un peu plus rapides. Bien sûr, en échange, vous avez la charge de gérer le maintien de l'ordre des pages de données sur INSERT , UPDATE , et DELETE . Une table de tas, cependant, nécessite une seconde écriture dans l'IAM.
Si votre requête a une RANGE opérateur (ex :SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100 ), alors une table en cluster (étant dans un ordre garanti) serait plus efficace - car elle pourrait utiliser les pages d'index pour trouver la ou les pages de données pertinentes. Un tas devrait analyser toutes les lignes, car il ne peut pas compter sur l'ordre.
Et, bien sûr, un index clusterisé vous permet d'effectuer une CLUSTERED INDEX SEEK, ce qui est à peu près optimal pour les performances... un tas sans index entraînerait toujours une analyse de table.
Donc :
-
Pour votre exemple de requête où vous sélectionnez toutes les lignes, la seule différence est la liste à double liaison maintenue par un index clusterisé. Cela devrait rendre votre table en cluster juste un tout petit peu plus rapide qu'un tas avec un grand nombre de lignes.
-
Pour une requête avec un
WHEREclause qui peut être (au moins partiellement) satisfaite par l'index clusterisé, vous sortirez en tête en raison de l'ordre - vous n'aurez donc pas à parcourir toute la table. -
Pour une requête qui n'est pas satisfaite par l'index clusterisé, vous êtes à peu près égal... encore une fois, la seule différence étant cette liste à double lien pour l'analyse séquentielle. Dans les deux cas, vous êtes sous-optimal.
-
Pour
INSERT,UPDATE, etDELETEun tas peut ou non gagner. Le tas n'a pas à maintenir l'ordre, mais nécessite une seconde écriture dans l'IAM. Je pense que la différence de performances relative serait négligeable, mais aussi assez dépendante des données.
Microsoft a un livre blanc qui compare un index clusterisé à un index non clusterisé équivalent sur un tas (pas exactement le même que celui dont j'ai parlé ci-dessus, mais proche). Leur conclusion est essentiellement de mettre un index clusterisé sur toutes les tables. Je ferai de mon mieux pour résumer leurs résultats (encore une fois, notez qu'ils comparent vraiment un index non clusterisé à un index clusterisé ici - mais je pense que c'est relativement comparable):
INSERTperformances :l'index clusterisé gagne environ 3 % en raison de la deuxième écriture nécessaire pour un tas.UPDATEperformances :l'index clusterisé gagne environ 8 % en raison de la deuxième recherche nécessaire pour un tas.DELETEperformances :l'index clusterisé gagne environ 18 % en raison de la deuxième recherche nécessaire et de la deuxième suppression nécessaire de l'IAM pour un tas.- seul
SELECTperformances :l'index clusterisé gagne environ 16 % en raison de la deuxième recherche nécessaire pour un tas. - plage
SELECTperformances :l'index clusterisé gagne environ 29 % en raison de l'ordre aléatoire d'un tas. INSERTsimultané :la table de tas gagne de 30 % sous charge en raison des fractionnements de page pour l'index clusterisé.
