Quelle est la différence entre un scan de table et un scan d'index clusterisé?

Dans une table sans index clusterisé (table de segments), les pages de données ne sont pas liées entre elles. Par conséquent, les pages qui se déplacent nécessitent une search dans la table d' allocation d'index .

Une table en cluster, cependant, a ses pages de données liées dans une list doublement liée – ce qui rend les parsings séquentielles un peu plus rapide. Bien sûr, en échange, vous devez gérer les pages de données dans INSERT , UPDATE et DELETE . Une table de tas, cependant, nécessite une seconde écriture à l'IAM.

Si votre requête a un opérateur RANGE (par exemple: 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 find datatables pertinentes page (s). Un tas devrait scanner toutes les lignes, puisqu'il ne peut pas countr sur la command.

Et, bien sûr, un index clusterisé vous permet de faire une RECHERCHE D'INDICE CLUSTERED, ce qui est plutôt optimal pour les performances … un tas sans index entraînerait toujours un scan de la table.

Alors:

• Pour votre exemple de requête où vous select toutes les lignes, la seule différence est la list doublement chaînée qu'un index clusterisé gère. Cela devrait rendre votre table en cluster juste un peu plus rapide qu'un tas avec un grand nombre de lignes.

• Pour une requête avec une clause WHERE qui peut être satisfaite (au less partiellement) par l'index clusterisé, vous en sortirez en raison de la command – vous n'aurez donc pas besoin d'parsingr 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 list doublement liée pour l'parsing séquentielle. Dans les deux cas, vous êtes sous-optimal.

• Pour INSERT , UPDATE et DELETE un tas peut ou ne peut pas gagner. Le tas n'a pas besoin de maintenir l'ordre, mais nécessite une seconde écriture dans l'IAM. Je pense que la différence de performance relative serait négligeable, mais aussi 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 je l'ai discuté 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):

• Performances INSERT : l'index clusterisé gagne environ 3% en raison de la deuxième écriture nécessaire pour un tas.
• Performances UPDATE : l'index clusterisé gagne environ 8% en raison de la deuxième search nécessaire pour un tas.
• DELETE performances: l'index clusterisé gagne environ 18% en raison de la deuxième search nécessaire et de la deuxième suppression requirejse de l'IAM pour un tas.
• Performance SELECT unique: l'index clusterisé gagne environ 16% en raison de la deuxième search nécessaire pour un tas.
• Gamme SELECT performance: l'index clusterisé gagne environ 29% en raison de l'ordre random d'un tas.
• INSERT concurrent: la table heap gagne 30% sous la charge en raison des fractionnements de page pour l'index clusterisé.

http://msdn.microsoft.com/en-us/library/aa216840(SQL.80).aspx

L'opérateur logique et physique d'parsing d'index en cluster parsing l'index en cluster spécifié dans la colonne Argument. Lorsqu'un prédicat facultatif WHERE :() est présent, seules les lignes qui satisfont le prédicat sont renvoyées. Si la colonne Argument contient la clause ORDERED, le processeur de requêtes a demandé que la sortie des lignes soit renvoyée dans l'ordre dans lequel l'index clusterisé les a sortingées. Si la clause ORDERED n'est pas présente, le moteur de stockage parsing l'index de la manière optimale (ne garantissant pas la sortie à sortinger).

http://msdn.microsoft.com/en-us/library/aa178416(SQL.80).aspx

L'opérateur logique et physique Analyse de table récupère toutes les lignes de la table spécifiée dans la colonne Argument. Si un prédicat WHERE :() apparaît dans la colonne Argument, seules les lignes qui satisfont le prédicat sont renvoyées.

Une parsing de table doit examiner chaque rangée de la table. L'parsing d'index en cluster doit uniquement parsingr l'index. Il n'parsing pas tous les loggings de la table. C'est le point, vraiment, des indices.