Quelle est la différence entre une analyse de table et une analyse d'index en cluster?

Question

Etant donné qu’un Table Scan et un Clustered Index Scan analysent essentiellement tous les enregistrements du tableau, pourquoi une analyse par index en cluster est-elle supposée meilleure?

Par exemple, quelle est la différence de performances entre les éléments suivants lorsqu'il y a plusieurs enregistrements?

 declare @temp table(
    SomeColumn varchar(50)
)

insert into @temp
select 'SomeVal'

select * from @temp

-----------------------------

declare @temp table(
    RowID int not null identity(1,1) primary key,
    SomeColumn varchar(50)
)

insert into @temp
select 'SomeVal'

select * from @temp
 

Answer 1

Dans une table sans index cluster (une table heap), les pages de données ne sont pas liés ensemble parcourant les pages nécessite une recherche dans l'Index plan d'Allocation.

Un cluster tableau, cependant, il est des pages de données liées dans une liste doublement chaînée - faire des analyses séquentielles un peu plus vite. Bien sûr, en échange, vous avez la surcharge de traiter en conservant les données des pages dans l'ordre sur les Insertions, Mises à jour et des Suppressions. Une table heap, cependant, nécessite un deuxième écrire à l'IAM.

Si votre requête a une GAMME de l'opérateur (par exemple., SELECT * from TABLE where Id ENTRE 1 ET 100), puis un cluster tableau (dans un ordre garanti) serait plus efficace qu'elle pourrait l'utiliser les pages d'index pour trouver les données pertinentes page(s). Un tas aurait à analyser toutes les lignes, car il ne peut pas compter sur la commande.

Et, bien sûr, un index cluster permet de faire une recherche d'INDEX CLUSTER, qui est à peu près optimal pour la performance...un tas avec aucun index ne serait toujours le résultat dans une analyse de la table.

Donc:

• Pour votre exemple de requête lorsque vous sélectionnez toutes les lignes, la seule différence est la liste doublement chaînée un index cluster maintient. Cela devrait rendre votre cluster table juste un tout petit peu plus rapide qu'un tas avec un grand nombre de lignes.

• Pour une requête avec une clause where peut être (au moins partiellement) satisfait par l'index cluster, vous pourrez sortir à l'avance en raison de la commande - de sorte que vous n'aurez pas à analyser l'ensemble de la table.

• Pour une requête qui n'est pas satisfaits par l'index cluster, vous êtes assez bien même...encore une fois, la seule différence étant que la liste doublement chaînée de balayage séquentiel. Dans les deux cas, vous êtes sous-optimale.

• Pour les Insertions, Mises à jour et Supprime un segment peut ou ne peut pas gagner. Le tas n'a pas à maintenir l'ordre, mais nécessite un deuxième écrire à l'IAM. Je pense que la performance relative de la différence sera négligeable, mais aussi assez de données dépendantes.

Microsoft dispose d'un livre blanc , qui se compare à un index cluster équivalent d'un index non ordonné en clusters sur un segment de mémoire (pas exactement la même comme je l'ai expliqué ci-dessus, mais à proximité). Leur conclusion est essentiellement de mettre un index cluster sur tous les tableaux. Je vais faire de mon mieux pour résumer leurs résultats (encore une fois, notez qu'ils sont vraiment comparer un index non-cluster à un cluster indice ici - mais je pense que c'est relativement comparables):

• INSERT performances: index cluster gagne environ 3% en raison de la deuxième écriture nécessaires pour un segment.
• UPDATE performances: index cluster gagne par environ 8% en raison de la deuxième recherche nécessaire pour un segment.
• DELETE performances: index cluster gagne par environ 18% en raison de la deuxième recherche nécessaire et la deuxième supprimer nécessaires à partir de l'IAM pour un segment.
• seul SELECT performances: index cluster victoires de près de 16% en raison de la deuxième recherche nécessaire pour un segment.
• gamme SELECT performances: index cluster victoires d'environ 29% en raison de l'aléatoire de la commande pour un segment.
• simultanées INSERT: tas victoires de table de 30% en vertu de la charge due à la page divise pour l'index cluster.

Answer 2

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

L'Analyse d'Index Cluster opérateur logique et physique des scans de l'index cluster spécifié dans la colonne Argument. Lorsqu'une option OÙ:() prédicat est présent, seules les lignes qui satisfont le prédicat sont retournées. Si l'Argument de la colonne contient la clause ordered, le processeur de requêtes a demandé que les lignes de sortie de être rentré dans l'ordre dans lequel l'index cluster a trié. Si la commande de la clause n'est pas présent, le stockage, le moteur de scan dans l'index de façon optimale (ne garantissant pas la sortie pour être classé).

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

Le Tableau d'Analyse logique et physique de l'opérateur 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 retournées.

Answer 3

Une analyse de table doit examiner chaque ligne de la table. L'analyse d'index en cluster doit uniquement analyser l'index. Il n’analyse pas tous les enregistrements de la table. C'est le point, vraiment, des indices.