Devrais-je utiliser plusieurs index à un seul champ, au lieu d'index spécifiques à plusieurs colonnes?

Cette question concerne l'efficacité d'une technique d'indexation SQL Server. Je pense que c'est connu comme "intersection d'index".

Je travaille avec une application SQL Server (2008) existante qui pose un certain nombre de problèmes de performances et de stabilité. Les développeurs ont fait des choses étranges avec l'indexation. Je n'ai pas réussi à obtenir de points de repère concluants sur ces questions, et je ne trouve pas non plus de documentation de qualité sur les internets.

Il y a beaucoup de colonnes interrogeables sur une table. Les développeurs ont créé un index de colonne unique sur CHAQUE des colonnes pouvant faire l'objet d'une recherche. La théorie était que SQL Server serait capable de combiner (intersecter) chacun de ces index pour accéder efficacement à la table dans la plupart des cas. Voici un exemple simplifié (la table réelle a plus de champs):

CREATE TABLE [dbo].[FatTable](
    [id] [bigint] IDENTITY(1,1) NOT NULL,
    [col1] [nchar](12) NOT NULL,
    [col2] [int] NOT NULL,
    [col3] [varchar](2000) NOT NULL, ...

CREATE NONCLUSTERED INDEX [IndexCol1] ON [dbo].[FatTable]  ( [col1] ASC )
CREATE NONCLUSTERED INDEX [IndexCol2] ON [dbo].[FatTable] ( [col2] ASC )

select * from fattable where col1 = '2004IN' 
select * from fattable where col1 = '2004IN' and col2 = 4

Je pense que plusieurs index de colonnes ciblés sur les critères de recherche sont bien meilleurs, mais je me trompe peut-être. J'ai vu des plans de requête montrant que SQL Server faisait une correspondance de hachage sur deux recherches d'index. Cela a peut-être du sens lorsque vous ne savez pas comment la table est recherchée? Merci.

Ce dont vous avez besoin, ce sont des index couvrant , c'est à dire. des index pouvant satisfaire une requête par eux-mêmes. Mais un index 'couvrant' a un problème: il couvre une requête spécifique . Donc, pour développer une bonne stratégie d’indexation, vous devez comprendre votre charge de travail: quelles requêtes arrivent dans la base de données, lesquelles sont critiques et lesquelles ne le sont pas, à quelle fréquence chaque type de requête est exécuté, etc., etc. équilibrez cela par rapport au coût d'écriture et de mise à jour de chaque index, et voilà votre stratégie d'indexation. Si cela semble compliqué qui est parce qu'il est compliqué.

Cependant, vous pouvez appliquer certaines règles empiriques. Le MSDN couvre assez bien les bases:

• Principes de base de la conception d'index
• Directives générales de conception d'index
• Directives de conception d'index groupés
• Directives de conception d'index non clusterisé

Il existe également une multitude d'articles rédigés par la communauté, par exemple. Enregistrement de diffusion sur le Web - DBA Darwin Awards: Index Edition .

Et pour répondre spécifiquement à votre question: des index séparés sur chaque colonne peuvent fonctionner, à condition que chaque colonne ait une sélectivité élevée (plusieurs valeurs distinctes, chaque valeur apparaissant seulement quelques fois dans la base de données). Le plan d'accès obtenu à l'aide d'une jointure par hachage entre deux analyses de plages d'index fonctionne généralement assez bien. Les colonnes à faible sélectivité (quelques valeurs distinctes, chaque valeur apparaissant plusieurs fois dans la base de données) n'ont aucun sens à être indexées par elles-mêmes, l'optimiseur de requête les ignorera tout simplement. Cependant, les colonnes à faible sélectivité constituent souvent de bonnes clés composites lorsqu'elles sont associées à une colonne à sélectivité élevée.