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

Question

Puisque tous deux un Table Scan et un Clustered Index Scan analyse essentiellement tous les enregistrements de la table, pourquoi une analyse d'index clusterisé est-elle censée être meilleure ?

À titre d'exemple : quelle est la différence de performances entre les éléments suivants lorsqu'il y a de nombreux 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 clusterisé (une table de tas), les pages de données ne sont pas liées entre elles - le parcours des pages nécessite donc un recherche dans la carte d'allocation d'index.

Une table clusterisée, cependant, a son pages de données liées dans une liste doublement chaînée - rendre les analyses séquentielles un peu plus rapides.Bien sûr, en échange, vous avez la charge de gérer les pages de données en ordre sur INSERT, UPDATE, et DELETE.Toutefois, une table de tas nécessite une seconde écriture dans l'IAM.

Si votre requête a un RANGE opérateur (ex. : SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100), alors une table clusterisée (é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 s'appuyer sur le classement.

Et, bien sûr, un index clusterisé vous permet d'effectuer une RECHERCHE D'INDEX CLUSTERED, ce qui est à peu près optimal en termes de performances... un tas sans index entraînerait toujours une analyse de table.

Donc:

• Pour votre exemple de requête dans laquelle vous sélectionnez toutes les lignes, la seule différence est la liste doublement chaînée maintenue par un index clusterisé.Cela devrait rendre votre table clusterisée un peu plus rapide qu'un tas avec un grand nombre de lignes.

• Pour une requête avec un WHERE clause qui peut être (au moins partiellement) satisfaite par l'index clusterisé, vous obtiendrez l'avantage grâce à l'ordre - vous n'aurez donc pas à analyser la table entière.

• 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 doublement chaînée pour l'analyse séquentielle.Dans les deux cas, vous n’êtes pas optimal.

• Pour INSERT, UPDATE, et DELETE un tas peut gagner ou non.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 performances relative serait négligeable, mais dépendrait également beaucoup des données.

Microsoft a un papier blanc qui compare un index clusterisé à un index non clusterisé équivalent sur un tas (pas exactement la même chose que celle 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 ici en réalité un index non clusterisé à un index clusterisé - mais je pense que c'est relativement comparable) :

• INSERT performance:l'index clusterisé gagne d'environ 3 % en raison de la deuxième écriture nécessaire pour un tas.
• UPDATE performance:l'index clusterisé gagne d'environ 8 % en raison de la deuxième recherche nécessaire pour un tas.
• DELETE performance:L'index clusterisé gagne d'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.
• célibataire SELECT performance:l'index clusterisé gagne environ 16 % en raison de la deuxième recherche nécessaire pour un tas.
• gamme SELECT performance:l'index clusterisé gagne d'environ 29 % en raison de l'ordre aléatoire d'un tas.
• concurrent INSERT:la table de tas gagne de 30 % sous charge en raison des fractionnements de pages pour l'index clusterisé.

Answer 2

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

L’opérateur logique et physique Clustered Index Scan analyse l’index cluster spécifié dans la colonne Argument.Lorsqu'un prédicat facultatif WHERE:() est présent, seules les lignes qui satisfont au 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 triées.Si la clause ORDERED n'est pas présente, le moteur de stockage analysera l'index de la manière optimale (ne garantissant pas que la sortie soit triée).

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

L'opérateur logique et physique Table Scan 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 au prédicat sont renvoyées.

Answer 3

Une analyse de table doit examiner chaque ligne du tableau.L'analyse de l'index clusterisé doit uniquement analyser l'index.Il n'analyse pas tous les enregistrements de la table.C’est vraiment l’intérêt des indices.