Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur les index plusieurs question pour les perfs

les index plusieurs question pour les perfs

11 réponses
Avatar
Christophe
Voila j'ai des questions sur les index !


que vaut 'il mieux faire pour avoir des performances optimales ?


J'ai plusieurs dizaines de requetes plus ou moins differentes sur mes
tables.
le dba actuel a créer plusieurs sortent d'index .


Exemple
COL1
COL1 & COL2
COL2
COL3
COL1 & COL3
COL2 & COL3
COL1 & COL2 & COL3


je me demande si de mettre autant d'index que de possibilité est bon
réélement pour les perfs ou si SQL peut se tromper du coup en prenant
l'index pas optimal ?


est-ce que
COL1
COL2
COL3

ne serait pas suffisant pour couvrir tous les cas ?


en bref que vaut'il mieux choisir comme methode d'index ?
Merci par avance.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Philippe T [MS]
Bonjour,

COL1 => inutile car inclus dans le
deuxième COL1 & COL2
COL1 & COL2 => inutile car inclus dans le deuxième
COL1 & COL2 & COL3
COL2 => inutile car inclus dans le
deuxième COL2 & COL3
COL3
COL1 & COL3
COL2 & COL3
COL1 & COL2 & COL3


Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Christophe" wrote in message
news:eWqJF%
Voila j'ai des questions sur les index !


que vaut 'il mieux faire pour avoir des performances optimales ?


J'ai plusieurs dizaines de requetes plus ou moins differentes sur mes
tables.
le dba actuel a créer plusieurs sortent d'index .


Exemple
COL1
COL1 & COL2
COL2
COL3
COL1 & COL3
COL2 & COL3
COL1 & COL2 & COL3


je me demande si de mettre autant d'index que de possibilité est bon
réélement pour les perfs ou si SQL peut se tromper du coup en prenant
l'index pas optimal ?


est-ce que
COL1
COL2
COL3

ne serait pas suffisant pour couvrir tous les cas ?


en bref que vaut'il mieux choisir comme methode d'index ?
Merci par avance.







Avatar
Christophe
Oui mais alors ma question

c'est il vaut mieux un seul index avec
Col1 & Col2 & Col3

ou 3 index unique
COL1
COL2
COL3


Sachant que les where des requetes peuvent etre de multiple combinaison.


Where Col1 = XXX
ou
Where col1 = XXX and COL3 = XXX
ou
Where COL2 = XX

etc....





"Philippe T [MS]" a écrit dans le message de
news:e$
Bonjour,

COL1 => inutile car inclus dans le
deuxième COL1 & COL2
COL1 & COL2 => inutile car inclus dans le deuxième
COL1 & COL2 & COL3
COL2 => inutile car inclus dans le
deuxième COL2 & COL3
COL3
COL1 & COL3
COL2 & COL3
COL1 & COL2 & COL3


Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Christophe" wrote in message
news:eWqJF%
> Voila j'ai des questions sur les index !
>
>
> que vaut 'il mieux faire pour avoir des performances optimales ?
>
>
> J'ai plusieurs dizaines de requetes plus ou moins differentes sur mes
> tables.
> le dba actuel a créer plusieurs sortent d'index .
>
>
> Exemple
> COL1
> COL1 & COL2
> COL2
> COL3
> COL1 & COL3
> COL2 & COL3
> COL1 & COL2 & COL3
>
>
> je me demande si de mettre autant d'index que de possibilité est bon
> réélement pour les perfs ou si SQL peut se tromper du coup en prenant
> l'index pas optimal ?
>
>
> est-ce que
> COL1
> COL2
> COL3
>
> ne serait pas suffisant pour couvrir tous les cas ?
>
>
> en bref que vaut'il mieux choisir comme methode d'index ?
> Merci par avance.
>
>
>
>
>




Avatar
Philippe T [MS]
Bonjour,

Cela dépend de ce que vous voulez optimiser.

Si vous avez une clause WHERE avec Col1 et Col2, il est préférable de faire
un index combiné.

Il faut voir les index comme des tables de références repointant vers les
tables de données.


Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Christophe" wrote in message
news:
Oui mais alors ma question

c'est il vaut mieux un seul index avec
Col1 & Col2 & Col3

ou 3 index unique
COL1
COL2
COL3


Sachant que les where des requetes peuvent etre de multiple combinaison.


Where Col1 = XXX
ou
Where col1 = XXX and COL3 = XXX
ou
Where COL2 = XX

etc....





"Philippe T [MS]" a écrit dans le message
de
news:e$
Bonjour,

COL1 => inutile car inclus dans le
deuxième COL1 & COL2
COL1 & COL2 => inutile car inclus dans le
deuxième
COL1 & COL2 & COL3
COL2 => inutile car inclus dans le
deuxième COL2 & COL3
COL3
COL1 & COL3
COL2 & COL3
COL1 & COL2 & COL3


Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Christophe" wrote in message
news:eWqJF%
> Voila j'ai des questions sur les index !
>
>
> que vaut 'il mieux faire pour avoir des performances optimales ?
>
>
> J'ai plusieurs dizaines de requetes plus ou moins differentes sur mes
> tables.
> le dba actuel a créer plusieurs sortent d'index .
>
>
> Exemple
> COL1
> COL1 & COL2
> COL2
> COL3
> COL1 & COL3
> COL2 & COL3
> COL1 & COL2 & COL3
>
>
> je me demande si de mettre autant d'index que de possibilité est bon
> réélement pour les perfs ou si SQL peut se tromper du coup en prenant
> l'index pas optimal ?
>
>
> est-ce que
> COL1
> COL2
> COL3
>
> ne serait pas suffisant pour couvrir tous les cas ?
>
>
> en bref que vaut'il mieux choisir comme methode d'index ?
> Merci par avance.
>
>
>
>
>








Avatar
Christophe
oui je vois bien le principe mais ma question c'est quand on a de multiple
causes where

mieux vaut isoler un par un les index à faire ?
ou alors mieux vaut la combinaison sachant que dans la combinaison tout y es
?

C'est pas tres clair de la facon dont SQL va s'y prendre et si au final il
gagne ou perd du temps selon les combinaisons ?

Ch.


"Philippe T [MS]" a écrit dans le message de
news:
Bonjour,

Cela dépend de ce que vous voulez optimiser.

Si vous avez une clause WHERE avec Col1 et Col2, il est préférable de


faire
un index combiné.

Il faut voir les index comme des tables de références repointant vers les
tables de données.


Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Christophe" wrote in message
news:
> Oui mais alors ma question
>
> c'est il vaut mieux un seul index avec
> Col1 & Col2 & Col3
>
> ou 3 index unique
> COL1
> COL2
> COL3
>
>
> Sachant que les where des requetes peuvent etre de multiple combinaison.
>
>
> Where Col1 = XXX
> ou
> Where col1 = XXX and COL3 = XXX
> ou
> Where COL2 = XX
>
> etc....
>
>
>
>
>
> "Philippe T [MS]" a écrit dans le message
> de
> news:e$
>> Bonjour,
>>
>> COL1 => inutile car inclus dans


le
>> deuxième COL1 & COL2
>> COL1 & COL2 => inutile car inclus dans le
>> deuxième
>> COL1 & COL2 & COL3
>> COL2 => inutile car inclus dans


le
>> deuxième COL2 & COL3
>> COL3
>> COL1 & COL3
>> COL2 & COL3
>> COL1 & COL2 & COL3
>>
>>
>> Phil.
>> ________________________________________________________
>> Philippe TROTIN
>> Microsoft Services France http://www.microsoft.com/france
>> "Christophe" wrote in message
>> news:eWqJF%
>> > Voila j'ai des questions sur les index !
>> >
>> >
>> > que vaut 'il mieux faire pour avoir des performances optimales ?
>> >
>> >
>> > J'ai plusieurs dizaines de requetes plus ou moins differentes sur mes
>> > tables.
>> > le dba actuel a créer plusieurs sortent d'index .
>> >
>> >
>> > Exemple
>> > COL1
>> > COL1 & COL2
>> > COL2
>> > COL3
>> > COL1 & COL3
>> > COL2 & COL3
>> > COL1 & COL2 & COL3
>> >
>> >
>> > je me demande si de mettre autant d'index que de possibilité est bon
>> > réélement pour les perfs ou si SQL peut se tromper du coup en prenant
>> > l'index pas optimal ?
>> >
>> >
>> > est-ce que
>> > COL1
>> > COL2
>> > COL3
>> >
>> > ne serait pas suffisant pour couvrir tous les cas ?
>> >
>> >
>> > en bref que vaut'il mieux choisir comme methode d'index ?
>> > Merci par avance.
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>




Avatar
Philippe T [MS]
Bonjour,

A mon sens, il est préférable de faire un index multi-colonne et
éventuellement d'ajouter les indexes mono colonnes souhaitable en fonction
des procédures a optimiser.

Désolé mais il n'y a pas de recette magique :-(


Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Christophe" wrote in message
news:%
oui je vois bien le principe mais ma question c'est quand on a de multiple
causes where

mieux vaut isoler un par un les index à faire ?
ou alors mieux vaut la combinaison sachant que dans la combinaison tout y
es
?

C'est pas tres clair de la facon dont SQL va s'y prendre et si au final il
gagne ou perd du temps selon les combinaisons ?

Ch.


"Philippe T [MS]" a écrit dans le message
de
news:
Bonjour,

Cela dépend de ce que vous voulez optimiser.

Si vous avez une clause WHERE avec Col1 et Col2, il est préférable de


faire
un index combiné.

Il faut voir les index comme des tables de références repointant vers les
tables de données.


Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Christophe" wrote in message
news:
> Oui mais alors ma question
>
> c'est il vaut mieux un seul index avec
> Col1 & Col2 & Col3
>
> ou 3 index unique
> COL1
> COL2
> COL3
>
>
> Sachant que les where des requetes peuvent etre de multiple
> combinaison.
>
>
> Where Col1 = XXX
> ou
> Where col1 = XXX and COL3 = XXX
> ou
> Where COL2 = XX
>
> etc....
>
>
>
>
>
> "Philippe T [MS]" a écrit dans le
> message
> de
> news:e$
>> Bonjour,
>>
>> COL1 => inutile car inclus dans


le
>> deuxième COL1 & COL2
>> COL1 & COL2 => inutile car inclus dans le
>> deuxième
>> COL1 & COL2 & COL3
>> COL2 => inutile car inclus dans


le
>> deuxième COL2 & COL3
>> COL3
>> COL1 & COL3
>> COL2 & COL3
>> COL1 & COL2 & COL3
>>
>>
>> Phil.
>> ________________________________________________________
>> Philippe TROTIN
>> Microsoft Services France http://www.microsoft.com/france
>> "Christophe" wrote in message
>> news:eWqJF%
>> > Voila j'ai des questions sur les index !
>> >
>> >
>> > que vaut 'il mieux faire pour avoir des performances optimales ?
>> >
>> >
>> > J'ai plusieurs dizaines de requetes plus ou moins differentes sur
>> > mes
>> > tables.
>> > le dba actuel a créer plusieurs sortent d'index .
>> >
>> >
>> > Exemple
>> > COL1
>> > COL1 & COL2
>> > COL2
>> > COL3
>> > COL1 & COL3
>> > COL2 & COL3
>> > COL1 & COL2 & COL3
>> >
>> >
>> > je me demande si de mettre autant d'index que de possibilité est bon
>> > réélement pour les perfs ou si SQL peut se tromper du coup en
>> > prenant
>> > l'index pas optimal ?
>> >
>> >
>> > est-ce que
>> > COL1
>> > COL2
>> > COL3
>> >
>> > ne serait pas suffisant pour couvrir tous les cas ?
>> >
>> >
>> > en bref que vaut'il mieux choisir comme methode d'index ?
>> > Merci par avance.
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>








Avatar
Christophe
Ok je vois !
Je pensais que trop d'index tué l'index ;)



"Philippe T [MS]" a écrit dans le message de
news:%
Bonjour,

A mon sens, il est préférable de faire un index multi-colonne et
éventuellement d'ajouter les indexes mono colonnes souhaitable en fonction
des procédures a optimiser.

Désolé mais il n'y a pas de recette magique :-(


Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Christophe" wrote in message
news:%
> oui je vois bien le principe mais ma question c'est quand on a de


multiple
> causes where
>
> mieux vaut isoler un par un les index à faire ?
> ou alors mieux vaut la combinaison sachant que dans la combinaison tout


y
> es
> ?
>
> C'est pas tres clair de la facon dont SQL va s'y prendre et si au final


il
> gagne ou perd du temps selon les combinaisons ?
>
> Ch.
>
>
> "Philippe T [MS]" a écrit dans le message
> de
> news:
>> Bonjour,
>>
>> Cela dépend de ce que vous voulez optimiser.
>>
>> Si vous avez une clause WHERE avec Col1 et Col2, il est préférable de
> faire
>> un index combiné.
>>
>> Il faut voir les index comme des tables de références repointant vers


les
>> tables de données.
>>
>>
>> Phil.
>> ________________________________________________________
>> Philippe TROTIN
>> Microsoft Services France http://www.microsoft.com/france
>> "Christophe" wrote in message
>> news:
>> > Oui mais alors ma question
>> >
>> > c'est il vaut mieux un seul index avec
>> > Col1 & Col2 & Col3
>> >
>> > ou 3 index unique
>> > COL1
>> > COL2
>> > COL3
>> >
>> >
>> > Sachant que les where des requetes peuvent etre de multiple
>> > combinaison.
>> >
>> >
>> > Where Col1 = XXX
>> > ou
>> > Where col1 = XXX and COL3 = XXX
>> > ou
>> > Where COL2 = XX
>> >
>> > etc....
>> >
>> >
>> >
>> >
>> >
>> > "Philippe T [MS]" a écrit dans le
>> > message
>> > de
>> > news:e$
>> >> Bonjour,
>> >>
>> >> COL1 => inutile car inclus


dans
> le
>> >> deuxième COL1 & COL2
>> >> COL1 & COL2 => inutile car inclus dans le
>> >> deuxième
>> >> COL1 & COL2 & COL3
>> >> COL2 => inutile car inclus


dans
> le
>> >> deuxième COL2 & COL3
>> >> COL3
>> >> COL1 & COL3
>> >> COL2 & COL3
>> >> COL1 & COL2 & COL3
>> >>
>> >>
>> >> Phil.
>> >> ________________________________________________________
>> >> Philippe TROTIN
>> >> Microsoft Services France http://www.microsoft.com/france
>> >> "Christophe" wrote in message
>> >> news:eWqJF%
>> >> > Voila j'ai des questions sur les index !
>> >> >
>> >> >
>> >> > que vaut 'il mieux faire pour avoir des performances optimales ?
>> >> >
>> >> >
>> >> > J'ai plusieurs dizaines de requetes plus ou moins differentes sur
>> >> > mes
>> >> > tables.
>> >> > le dba actuel a créer plusieurs sortent d'index .
>> >> >
>> >> >
>> >> > Exemple
>> >> > COL1
>> >> > COL1 & COL2
>> >> > COL2
>> >> > COL3
>> >> > COL1 & COL3
>> >> > COL2 & COL3
>> >> > COL1 & COL2 & COL3
>> >> >
>> >> >
>> >> > je me demande si de mettre autant d'index que de possibilité est


bon
>> >> > réélement pour les perfs ou si SQL peut se tromper du coup en
>> >> > prenant
>> >> > l'index pas optimal ?
>> >> >
>> >> >
>> >> > est-ce que
>> >> > COL1
>> >> > COL2
>> >> > COL3
>> >> >
>> >> > ne serait pas suffisant pour couvrir tous les cas ?
>> >> >
>> >> >
>> >> > en bref que vaut'il mieux choisir comme methode d'index ?
>> >> > Merci par avance.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>




Avatar
SQLpro [MVP]
1) dans les index multicolonnes, les données sont concaténées.
2) les statistiques ne sont collectées que pour la première colonne

Conclusion :
1) placez la colonne la plus sélective en premier
2) n'utilisez pas de recherche directe sur les colonnes interne de l'index.
3) réordonnez vos requêtes en tenant compte de 1 et 2

Exemple :

CREATE TABLE T_PATIENT_PTT
(PTT_ID ...
PTT_NOM ...
PTT_PRENOM ...
PTT_NUMSECU ... )

recherches opérées sur Nom, Prenom, NumSecu....

Soit 3 index
Soit 1 index NUMSECU / NOM / PRENOM + éventuellement d'autres index (NOM
/ PRENOM et NOM)

Mais gare au volume des données, car effectivement TROP D'INDEX TUE
L'INDEX !

A +



Christophe a écrit :
Voila j'ai des questions sur les index !


que vaut 'il mieux faire pour avoir des performances optimales ?


J'ai plusieurs dizaines de requetes plus ou moins differentes sur mes
tables.
le dba actuel a créer plusieurs sortent d'index .


Exemple
COL1
COL1 & COL2
COL2
COL3
COL1 & COL3
COL2 & COL3
COL1 & COL2 & COL3


je me demande si de mettre autant d'index que de possibilité est bon
réélement pour les perfs ou si SQL peut se tromper du coup en prenant
l'index pas optimal ?


est-ce que
COL1
COL2
COL3

ne serait pas suffisant pour couvrir tous les cas ?


en bref que vaut'il mieux choisir comme methode d'index ?
Merci par avance.









--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Christophe
Donc en gros pour couvrir un maximum de cas
pour un maximum de developpers qui vont pas forcement tenir compte de tout
quand ils ecrivent leurs requetes !

le mieux c'est d'indexer les colonnes les plus utilisées seules ?

Exemple
Col1
Col2
Col3

séparement parce que elle peuvent etre appellée seule et si j'ai bien
compris seule la premiere colonne d'un index multicolonne est gerée ?
2 comment cela se comporte t'il pour un where qui appelle la col1 et col3 si
ils sont indexés separement ?

Merci !!
on trouve jamais ces astuces la ?



"SQLpro [MVP]" a écrit dans le message de
news:
1) dans les index multicolonnes, les données sont concaténées.
2) les statistiques ne sont collectées que pour la première colonne

Conclusion :
1) placez la colonne la plus sélective en premier
2) n'utilisez pas de recherche directe sur les colonnes interne de


l'index.
3) réordonnez vos requêtes en tenant compte de 1 et 2

Exemple :

CREATE TABLE T_PATIENT_PTT
(PTT_ID ...
PTT_NOM ...
PTT_PRENOM ...
PTT_NUMSECU ... )

recherches opérées sur Nom, Prenom, NumSecu....

Soit 3 index
Soit 1 index NUMSECU / NOM / PRENOM + éventuellement d'autres index (NOM
/ PRENOM et NOM)

Mais gare au volume des données, car effectivement TROP D'INDEX TUE
L'INDEX !

A +



Christophe a écrit :
> Voila j'ai des questions sur les index !
>
>
> que vaut 'il mieux faire pour avoir des performances optimales ?
>
>
> J'ai plusieurs dizaines de requetes plus ou moins differentes sur mes
> tables.
> le dba actuel a créer plusieurs sortent d'index .
>
>
> Exemple
> COL1
> COL1 & COL2
> COL2
> COL3
> COL1 & COL3
> COL2 & COL3
> COL1 & COL2 & COL3
>
>
> je me demande si de mettre autant d'index que de possibilité est bon
> réélement pour les perfs ou si SQL peut se tromper du coup en prenant
> l'index pas optimal ?
>
>
> est-ce que
> COL1
> COL2
> COL3
>
> ne serait pas suffisant pour couvrir tous les cas ?
>
>
> en bref que vaut'il mieux choisir comme methode d'index ?
> Merci par avance.
>
>
>
>
>


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************


Avatar
Philippe T [MS]
Bonjour,

Non, non, je ne pense pas que cela soit le message passé. Plus l'index va
contenir de précision et plus il va être efficace. La mise a jour des
statistiques de la première colonne ne veut pas dire que les colonnes
supplémentaires ne sont pas utiles dans l'index.

Les conseils de Frédéric sont judicieux :

1) placer la colonne la plus sélective en premier :
=> permet de restreindre le plus rapidement possible le sous ensemble de
l'index qui nous intéresse.
2) n'utilisez pas de recherche directe sur les colonnes interne de l'index :
=> Si l'index contient col1 et col2, une clause WHERE sur col2 ne va pas
être optimisé par cet index.
3) réordonnez vos requêtes en tenant compte de 1 et 2
=> Il faut au maximum avoir une clause WHERE correspondant aux index
positionné (en tenant compte de l'ordre des colonnes).

Les seules règles a considérer sont :
- ne pas avoir trop d'index sur des tables mises a jour fréquement car la
mise a jour de la table va induire le calcul de tous les indexes
sous-jacent.
- optimiser de préférence les procédures les plus importantes (fréquence
d'appel importante, jeux d'enregistrement manipulé sur des tables
volumineuses)

Bon courage.

Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Christophe" wrote in message
news:e$
Donc en gros pour couvrir un maximum de cas
pour un maximum de developpers qui vont pas forcement tenir compte de tout
quand ils ecrivent leurs requetes !

le mieux c'est d'indexer les colonnes les plus utilisées seules ?

Exemple
Col1
Col2
Col3

séparement parce que elle peuvent etre appellée seule et si j'ai bien
compris seule la premiere colonne d'un index multicolonne est gerée ?
2 comment cela se comporte t'il pour un where qui appelle la col1 et col3
si
ils sont indexés separement ?

Merci !!
on trouve jamais ces astuces la ?



"SQLpro [MVP]" a écrit dans le message de
news:
1) dans les index multicolonnes, les données sont concaténées.
2) les statistiques ne sont collectées que pour la première colonne

Conclusion :
1) placez la colonne la plus sélective en premier
2) n'utilisez pas de recherche directe sur les colonnes interne de


l'index.
3) réordonnez vos requêtes en tenant compte de 1 et 2

Exemple :

CREATE TABLE T_PATIENT_PTT
(PTT_ID ...
PTT_NOM ...
PTT_PRENOM ...
PTT_NUMSECU ... )

recherches opérées sur Nom, Prenom, NumSecu....

Soit 3 index
Soit 1 index NUMSECU / NOM / PRENOM + éventuellement d'autres index (NOM
/ PRENOM et NOM)

Mais gare au volume des données, car effectivement TROP D'INDEX TUE
L'INDEX !

A +



Christophe a écrit :
> Voila j'ai des questions sur les index !
>
>
> que vaut 'il mieux faire pour avoir des performances optimales ?
>
>
> J'ai plusieurs dizaines de requetes plus ou moins differentes sur mes
> tables.
> le dba actuel a créer plusieurs sortent d'index .
>
>
> Exemple
> COL1
> COL1 & COL2
> COL2
> COL3
> COL1 & COL3
> COL2 & COL3
> COL1 & COL2 & COL3
>
>
> je me demande si de mettre autant d'index que de possibilité est bon
> réélement pour les perfs ou si SQL peut se tromper du coup en prenant
> l'index pas optimal ?
>
>
> est-ce que
> COL1
> COL2
> COL3
>
> ne serait pas suffisant pour couvrir tous les cas ?
>
>
> en bref que vaut'il mieux choisir comme methode d'index ?
> Merci par avance.
>
>
>
>
>


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************






Avatar
Christophe
Merci de tou ces precieux conseils !

"Philippe T [MS]" a écrit dans le message de
news:%
Bonjour,

Non, non, je ne pense pas que cela soit le message passé. Plus l'index va
contenir de précision et plus il va être efficace. La mise a jour des
statistiques de la première colonne ne veut pas dire que les colonnes
supplémentaires ne sont pas utiles dans l'index.

Les conseils de Frédéric sont judicieux :

1) placer la colonne la plus sélective en premier :
=> permet de restreindre le plus rapidement possible le sous ensemble


de
l'index qui nous intéresse.
2) n'utilisez pas de recherche directe sur les colonnes interne de l'index


:
=> Si l'index contient col1 et col2, une clause WHERE sur col2 ne va


pas
être optimisé par cet index.
3) réordonnez vos requêtes en tenant compte de 1 et 2
=> Il faut au maximum avoir une clause WHERE correspondant aux index
positionné (en tenant compte de l'ordre des colonnes).

Les seules règles a considérer sont :
- ne pas avoir trop d'index sur des tables mises a jour fréquement car la
mise a jour de la table va induire le calcul de tous les indexes
sous-jacent.
- optimiser de préférence les procédures les plus importantes (fréquence
d'appel importante, jeux d'enregistrement manipulé sur des tables
volumineuses)

Bon courage.

Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Christophe" wrote in message
news:e$
> Donc en gros pour couvrir un maximum de cas
> pour un maximum de developpers qui vont pas forcement tenir compte de


tout
> quand ils ecrivent leurs requetes !
>
> le mieux c'est d'indexer les colonnes les plus utilisées seules ?
>
> Exemple
> Col1
> Col2
> Col3
>
> séparement parce que elle peuvent etre appellée seule et si j'ai bien
> compris seule la premiere colonne d'un index multicolonne est gerée ?
> 2 comment cela se comporte t'il pour un where qui appelle la col1 et


col3
> si
> ils sont indexés separement ?
>
> Merci !!
> on trouve jamais ces astuces la ?
>
>
>
> "SQLpro [MVP]" a écrit dans le message de
> news:
>> 1) dans les index multicolonnes, les données sont concaténées.
>> 2) les statistiques ne sont collectées que pour la première colonne
>>
>> Conclusion :
>> 1) placez la colonne la plus sélective en premier
>> 2) n'utilisez pas de recherche directe sur les colonnes interne de
> l'index.
>> 3) réordonnez vos requêtes en tenant compte de 1 et 2
>>
>> Exemple :
>>
>> CREATE TABLE T_PATIENT_PTT
>> (PTT_ID ...
>> PTT_NOM ...
>> PTT_PRENOM ...
>> PTT_NUMSECU ... )
>>
>> recherches opérées sur Nom, Prenom, NumSecu....
>>
>> Soit 3 index
>> Soit 1 index NUMSECU / NOM / PRENOM + éventuellement d'autres index


(NOM
>> / PRENOM et NOM)
>>
>> Mais gare au volume des données, car effectivement TROP D'INDEX TUE
>> L'INDEX !
>>
>> A +
>>
>>
>>
>> Christophe a écrit :
>> > Voila j'ai des questions sur les index !
>> >
>> >
>> > que vaut 'il mieux faire pour avoir des performances optimales ?
>> >
>> >
>> > J'ai plusieurs dizaines de requetes plus ou moins differentes sur mes
>> > tables.
>> > le dba actuel a créer plusieurs sortent d'index .
>> >
>> >
>> > Exemple
>> > COL1
>> > COL1 & COL2
>> > COL2
>> > COL3
>> > COL1 & COL3
>> > COL2 & COL3
>> > COL1 & COL2 & COL3
>> >
>> >
>> > je me demande si de mettre autant d'index que de possibilité est bon
>> > réélement pour les perfs ou si SQL peut se tromper du coup en prenant
>> > l'index pas optimal ?
>> >
>> >
>> > est-ce que
>> > COL1
>> > COL2
>> > COL3
>> >
>> > ne serait pas suffisant pour couvrir tous les cas ?
>> >
>> >
>> > en bref que vaut'il mieux choisir comme methode d'index ?
>> > Merci par avance.
>> >
>> >
>> >
>> >
>> >
>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage


SQL
>> Le site sur le langage SQL et les SGBDR :


http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning,


optimisation
>> ********************* http://www.datasapiens.com


***********************
>
>




1 2