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.
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.
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.
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.
>
>
>
>
>
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" <christophe@digital16-9.com> wrote in message
news:eWqJF%23fjGHA.1264@TK2MSFTNGP05.phx.gbl...
> 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.
>
>
>
>
>
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.
>
>
>
>
>
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.
>
>
>
>
>
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]" <ptrotin@online.microsoft.com> a écrit dans le message
de
news:e$fujHjjGHA.1508@TK2MSFTNGP04.phx.gbl...
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" <christophe@digital16-9.com> wrote in message
news:eWqJF%23fjGHA.1264@TK2MSFTNGP05.phx.gbl...
> 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.
>
>
>
>
>
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.
>
>
>
>
>
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
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
>> deuxième COL1 & COL2
>> COL1 & COL2 => inutile car inclus dans le
>> deuxième
>> COL1 & COL2 & COL3
>> COL2 => inutile car inclus dans
>> 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.
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
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
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" <christophe@digital16-9.com> wrote in message
news:OBG95KjjGHA.1936@TK2MSFTNGP04.phx.gbl...
> 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]" <ptrotin@online.microsoft.com> a écrit dans le message
> de
> news:e$fujHjjGHA.1508@TK2MSFTNGP04.phx.gbl...
>> Bonjour,
>>
>> COL1 => inutile car inclus dans
>> deuxième COL1 & COL2
>> COL1 & COL2 => inutile car inclus dans le
>> deuxième
>> COL1 & COL2 & COL3
>> COL2 => inutile car inclus dans
>> deuxième COL2 & COL3
>> COL3
>> COL1 & COL3
>> COL2 & COL3
>> COL1 & COL2 & COL3
>>
>>
>> Phil.
>> ________________________________________________________
>> Philippe TROTIN
>> Microsoft Services France http://www.microsoft.com/france
>> "Christophe" <christophe@digital16-9.com> wrote in message
>> news:eWqJF%23fjGHA.1264@TK2MSFTNGP05.phx.gbl...
>> > 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.
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
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
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
>> deuxième COL1 & COL2
>> COL1 & COL2 => inutile car inclus dans le
>> deuxième
>> COL1 & COL2 & COL3
>> COL2 => inutile car inclus dans
>> 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.
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
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
faireun 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.
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
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]" <ptrotin@online.microsoft.com> a écrit dans le message
de
news:eTypvMjjGHA.3496@TK2MSFTNGP04.phx.gbl...
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" <christophe@digital16-9.com> wrote in message
news:OBG95KjjGHA.1936@TK2MSFTNGP04.phx.gbl...
> 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]" <ptrotin@online.microsoft.com> a écrit dans le
> message
> de
> news:e$fujHjjGHA.1508@TK2MSFTNGP04.phx.gbl...
>> 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" <christophe@digital16-9.com> wrote in message
>> news:eWqJF%23fjGHA.1264@TK2MSFTNGP05.phx.gbl...
>> > 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.
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
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
faireun 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.
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
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
> causes where
>
> mieux vaut isoler un par un les index à faire ?
> ou alors mieux vaut la combinaison sachant que dans la combinaison tout
> es
> ?
>
> C'est pas tres clair de la facon dont SQL va s'y prendre et si au final
> 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
>> 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
> le
>> >> deuxième COL1 & COL2
>> >> COL1 & COL2 => inutile car inclus dans le
>> >> deuxième
>> >> COL1 & COL2 & COL3
>> >> COL2 => inutile car inclus
> 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
>> >> > 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.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
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" <christophe@digital16-9.com> wrote in message
news:%23UHXPajjGHA.4044@TK2MSFTNGP03.phx.gbl...
> oui je vois bien le principe mais ma question c'est quand on a de
> causes where
>
> mieux vaut isoler un par un les index à faire ?
> ou alors mieux vaut la combinaison sachant que dans la combinaison tout
> es
> ?
>
> C'est pas tres clair de la facon dont SQL va s'y prendre et si au final
> gagne ou perd du temps selon les combinaisons ?
>
> Ch.
>
>
> "Philippe T [MS]" <ptrotin@online.microsoft.com> a écrit dans le message
> de
> news:eTypvMjjGHA.3496@TK2MSFTNGP04.phx.gbl...
>> 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
>> tables de données.
>>
>>
>> Phil.
>> ________________________________________________________
>> Philippe TROTIN
>> Microsoft Services France http://www.microsoft.com/france
>> "Christophe" <christophe@digital16-9.com> wrote in message
>> news:OBG95KjjGHA.1936@TK2MSFTNGP04.phx.gbl...
>> > 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]" <ptrotin@online.microsoft.com> a écrit dans le
>> > message
>> > de
>> > news:e$fujHjjGHA.1508@TK2MSFTNGP04.phx.gbl...
>> >> Bonjour,
>> >>
>> >> COL1 => inutile car inclus
> le
>> >> deuxième COL1 & COL2
>> >> COL1 & COL2 => inutile car inclus dans le
>> >> deuxième
>> >> COL1 & COL2 & COL3
>> >> COL2 => inutile car inclus
> 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" <christophe@digital16-9.com> wrote in message
>> >> news:eWqJF%23fjGHA.1264@TK2MSFTNGP05.phx.gbl...
>> >> > 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
>> >> > 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.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
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
> causes where
>
> mieux vaut isoler un par un les index à faire ?
> ou alors mieux vaut la combinaison sachant que dans la combinaison tout
> es
> ?
>
> C'est pas tres clair de la facon dont SQL va s'y prendre et si au final
> 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
>> 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
> le
>> >> deuxième COL1 & COL2
>> >> COL1 & COL2 => inutile car inclus dans le
>> >> deuxième
>> >> COL1 & COL2 & COL3
>> >> COL2 => inutile car inclus
> 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
>> >> > 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.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
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.
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.
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.
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
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) 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
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) 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
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 ***********************
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 ***********************
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]" <brouardf@club-internet.fr> a écrit dans le message de
news:ewvBMfujGHA.836@TK2MSFTNGP02.phx.gbl...
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 ***********************
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 ***********************
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
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
ê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
> 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
> 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
>> / 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
>> Le site sur le langage SQL et les SGBDR :
>> Audit, conseil, expertise, formation, modélisation, tuning,
>> ********************* http://www.datasapiens.com
>
>
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
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
ê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" <christophe@digital16-9.com> wrote in message
news:e$xSY7vjGHA.1324@TK2MSFTNGP04.phx.gbl...
> Donc en gros pour couvrir un maximum de cas
> pour un maximum de developpers qui vont pas forcement tenir compte de
> 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
> si
> ils sont indexés separement ?
>
> Merci !!
> on trouve jamais ces astuces la ?
>
>
>
> "SQLpro [MVP]" <brouardf@club-internet.fr> a écrit dans le message de
> news:ewvBMfujGHA.836@TK2MSFTNGP02.phx.gbl...
>> 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
>> / 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
>> Le site sur le langage SQL et les SGBDR :
>> Audit, conseil, expertise, formation, modélisation, tuning,
>> ********************* http://www.datasapiens.com
>
>
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
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
ê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
> 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
> 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
>> / 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
>> Le site sur le langage SQL et les SGBDR :
>> Audit, conseil, expertise, formation, modélisation, tuning,
>> ********************* http://www.datasapiens.com
>
>