Discussion :

[sohm]

bonjour
j'ai une petite question sur les index dans ms sql server 2000.
voilà j'ai une requête du type

select * from table where col1 = @col1 and col2 = @col2
cette requête ne me retourne que quelques enregistrements

est ce que quelqu'un peut me confirme que pour tuner cette requête
il me suffit de créer un index contenant ces deux enregistrements

de plus, j'ai environ 100.000 enregistrements à ajouter en une fois avec environ 8 index
j'aimerai un retour niveau performance entre deux solutions :
- insertion simple
- désactivation des index, insertion des enregistrments, réactivation des index avec rebuild

merci d'avance
Philippe

[rudib]

Bonjour,

Tu peux en effet créer un index sur les deux colonnes, en choisissant en premier la colonne la plus sélective = celle qui contient le moins de doublons. Ensuite, en exécutant la requête en affichant le plan d'exécution, assure-toi que l'index est bien utilisé. Fais aussi la comparaison des pages lues en exécutant ta requête avant et après index après un SET STATISTICS IO ON.

Pour le deuxième sujet, dans ton cas, une suppression et recréation d'index après l'insert sera probablement plus efficace. Assure-toi de créer l'index ordonné avant les autres.

[ZERS]

assure-toi que l'index est bien utilisé.

Salut,

ca fait un paye que je fais du SQL et c'est vrai que je ne me suis jamais posé la question de savoir si un index est utilisé ou pas (sur pas DBA ).
Si tu positionnes un index sur une colonne, et que cette colonne fait partie d'une clause WHERE ou d'un jointure, l'index n'est pas forcément utilisé ?

Si c'est le cas, qu'est-ce qui détermine l'utilisation ou pas d'un index ?

[rudib]

Salut,

Eh bien non, l'index n'est pas forcément utilisé. SQL Server maintient des statistiques de distribution des données dans l'index (DBCC SHOW_STATISTICS ( table , index )). Il sait donc à peu près quel est sa sélectivité (le nombre de valeurs différentes dans l'index).
Si l'index est peu sélectif (= beaucoup de doublons), SQL server peut choisir de ne pas l'utiliser, parce que le coût de parcours de l'index pour chaque enregistrement à retourner est estimé plus élevé qu'un scan de la table.

Si dans l'exemple de sohm:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from table where col1 = @col1 and col2 = @col2

il y a un index non ordonné (col1, col2), et col1 est un bit qui comporte 50% de 1 et 50% de 0, ou simplement un int qui contient la valeur 10 sur peut-être 20% ou 30% des enregistrements, SQL Server peut très bien décider de se passer de l'index. Il aura raison, ce serait plus coûteux de l'utiliser.

Potentiellement, il pourrait aussi décider de ne pas utiliser l'index s'il sait qu'il doit retourner beaucoup d'enregistrements, et que, comme on le voit ici, il y a un SELECT * ou un SELECT de colonnes qui ne sont pas dans l'index, parce que le coût des bookmarks lookups ou des parcours de l'index ordonné sera estimé plus important que le scan. Mais c'est probablement plus rare.

Dans ces cas, inutile de créer un index qui ralentira les opérations DML (insert, update).

Il y a sans doute d'autres cas, par exemple s'il y a deux index, un sur col1 et l'autre sur col2, l'optimiseur pourrait choisir de n'en utiliser qu'un. C'est toujours une bonne idée de s'assurer que l'index est utilisé.

[ZERS]

très clair merci

D'une manière générale, je positionne des index sur les clefs fonctionnelles (qui ne sont pas forcément des clefs primaires). Si la clef fonctionnelle est bien designée, peu de doublons, donc utilisation quasi-sure d'un index.

Cdlt

[WOLO Laurent]

Non, détrompe toi !

Il ne suffit pas de créer un index puis d'inclure la colonne concernée par l'index dans la clause where pour qu'il l'optimiseur puisse l'inclure.
L'optimiseur choisit généralement le plan d'execution le plus éfficace.
Dans le cas par exemple ou vous avez crée plusieurs index pour la même colonne, l'optimiseur choisit l'index pouvant fournir le plus de performance.

Mais prénez garde, c'est un programme comme tout autre.
Il y a tout un tap de trucs et astuces à prendre en compte pour la création.
mais votre grand indicateur est le plan d'execution, vous devez être en mésure de l'analyser.

[usf70]

Est-il possible sous SQL Server de forcer l'utilisation d'un index, même si l'optimiseur ne l'aurait pas forcément pris ... Un peu comme les HINTS sous ORACLE ?

[rudib]

OULAH !

Oui, c'est possible, et non, il ne faut jamais le faire.

Cela équivaut à jeter des peaux de banane devant toi dans un couloir obscur.

Tu peux indiquer le nom de l'index à utiliser dans un hint, comme ça, ça te permet de tout faire tomber le jour où tu changes le nom de l'index, et d'obtenir des performances dix fois pire le jour où l'état des données ou de la structure font que l'utilisation de cet index n'est plus la meilleure solution.

L'optimiseur de SQL Server est un moteur très performant, tu peux lui faire confiance.

[WOLO Laurent]

OULAH !
L'optimiseur de SQL Server est un moteur très performant, tu peux lui faire confiance.

L'optimiseur de SQL Serveur est très très futé, c'est le plus rapide à l'heure actuelle, pas besoin de souffrire avec les hints, c'est pas recommandé comme l'a dit rudib !

[rudib]

Une info supplémentaire : en SQL 2005, il y a une vue système qui permet de déterminer si un index a été utilisé : Sys.dm_db_index_usage_stats

Des exemples d'utilisation ici :
http://blogs.msdn.com/sqlcat/archive...12/502735.aspx