Pourquoi utilise requête index cluster quand il ne devrait pas?

Question

Laissez-nous supposer que j'ai une table nommée Catégorie dans une base de données SQL Server 2005. Catégorie a category_id (bigint, identité) comme clé primaire et le nom (nvarchar (50)). Il y a évidemment un index ordonné en clusters sur category_id, et je l'ai également ajouté un index non ordonnés en clusters sur le nom. Si je lance la requête

SELECT * 
FROM Category 
WHERE [name] like '%zz%'

et regardez le dit, il est le plan d'exécution via Management Studio 2005, en utilisant un scan index en cluster. L'index ordonné en clusters est sur category_id, et non sur le nom.

Pourquoi est-il dire que?

Answer 1

Le « comme '% zzz% » en grande partie annule l'avantage possible de l'indice, car il devra examiner chaque entrée afin de déterminer si elle correspond; et faire le « SELECT * » signifie qu'il aurait à faire une recherche à l'index ordonné en clusters pour obtenir toutes les données de la colonne sur les enregistrements appariés; l'optimiseur ne peut pas estimer combien de matches il y aura donc choisit l'index ordonné en clusters.

Essayez de changer à « comme« zz% » et de voir ce que vous obtenez.

Answer 2

Parce que dans votre exemple, [category_id] est le PK (identité), et ces ont un indice PKs cluster lié à leur disposition par défaut (dans MS-SQL vous pouvez avoir seulement 1 index ordonné en clusters).

En outre, comme vous ne mentionnez pas que [nom] a un index, SQL seulement a vraiment le PK disponible pour une analyse (et est donc regarder chaque ligne à un coût de 100%).

BTW: Voici un article intéressant sur les indices et à:

Licencié sous: CC-BY-SA avec attribution

Non affilié à dba.stackexchange