OVH Cloud OVH Cloud

Index (mettre ou ne pas mettre)

6 réponses
Avatar
Laurent
Bonjour,

J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne pas
mettre d'index car les temps de réponse (en consultation) sont dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi du
comment.

Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.

6 réponses

Avatar
François 37
http://sqlpro.developpez.com/

De par l'expérience des dev en SQL 2000
Il apparait que :
1. il faut une primary key integer pour les tables pour gérer les insertions
2. il est inutile d'indexer à moins de 1000 enregistrements
3. Il est inutile d'indexer sur des champs ayant une faible sélectivité
(True False)
4. faire attention comment on pose les requêtes

"Laurent" a écrit dans le message de
news:
Bonjour,

J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne


pas
mettre d'index car les temps de réponse (en consultation) sont dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible


selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi


du
comment.

Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.


Avatar
Patrice
Essaye Google ou http://sql.developpez.com/, le site de Fred...

Le problème revient à "le jeu en vaut il la chandelle" :
1) - ???
2) Le volume de l'index sera grand donc moins efficace à parcourir qu'un
index "compact"
3) Si l'index permet de choisir 1 ligne parmi 10000, il sera utile, si il
permet de choisir 5000 ligne parmi 10000, cela permet de n'éliminer q'une
ligne sur 2

"En consultation" ou en "mise à jour" ? Apès le problème est que les index
doivent être mis à jour...

Je pense que le plus simple est toujours de tester ton cas concret :
1) Est-ce que tu sélectionne sur cette colonne ?
2) Si oui est-ce que c'est long et/ou fréquent ?
3) Si tu ajoutes un index qu'est ce que tu gagnes ?

Par exemple un cas que tu ne cites pas concerne les tables de faible nombre
d'enregistrements. A priori SQL Server peut très bien décider de ne pas
utiliser l'index dans ce cas même si présent (en considérant que la lecture
totale d'une table de faible taille sera aussi rapide que de lire l'index
puis d'aller chercher la page concernée).

Patrice
--

"Laurent" a écrit dans le message de
news:
Bonjour,

J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne


pas
mettre d'index car les temps de réponse (en consultation) sont dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible


selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi


du
comment.

Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.


Avatar
Fabian SIRACH [MS]
Bonjour,

Si le design de votre base est terminé et que vous avez des données à
disposition, vous pouvez utiliser "l'Index Tuning Wizard" de SQL Server qui
vous donnera une première idée des optimisations possibles sur la table et
vous proposer l'ajout ou non d'index sur les colonnes pertinentes aux
requêtes utilisées.

Cordialement

Fabian


"Patrice" wrote in message
news:%
Essaye Google ou http://sql.developpez.com/, le site de Fred...

Le problème revient à "le jeu en vaut il la chandelle" :
1) - ???
2) Le volume de l'index sera grand donc moins efficace à parcourir qu'un
index "compact"
3) Si l'index permet de choisir 1 ligne parmi 10000, il sera utile, si il
permet de choisir 5000 ligne parmi 10000, cela permet de n'éliminer q'une
ligne sur 2

"En consultation" ou en "mise à jour" ? Apès le problème est que les index
doivent être mis à jour...

Je pense que le plus simple est toujours de tester ton cas concret :
1) Est-ce que tu sélectionne sur cette colonne ?
2) Si oui est-ce que c'est long et/ou fréquent ?
3) Si tu ajoutes un index qu'est ce que tu gagnes ?

Par exemple un cas que tu ne cites pas concerne les tables de faible
nombre
d'enregistrements. A priori SQL Server peut très bien décider de ne pas
utiliser l'index dans ce cas même si présent (en considérant que la
lecture
totale d'une table de faible taille sera aussi rapide que de lire l'index
puis d'aller chercher la page concernée).

Patrice
--

"Laurent" a écrit dans le message de
news:
Bonjour,

J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne


pas
mettre d'index car les temps de réponse (en consultation) sont dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible


selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi


du
comment.

Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.






Avatar
Med Bouchenafa
> En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY.
C'est à vous de les mettre en place si le nombre de ligne en vaut la
chandelle



Il est impossible de créer une FOREIGN KEY référençant une colonne qui ne
possède pas un INDEX UNIQUE de manière directe ou indirercte
Seules les colonnes en PRIMARY KEY, UNIQUE ou possèdant un INDEX UNIQUE
peuvent être référencées

--
Bien cordialement
Med Bouchenafa

"brouardf" a écrit dans le message de news:

Laurent a écrit :
Bonjour,

J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas mettre d'index car les temps de réponse (en consultation) sont
dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du comment.

Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.




en complément si email est muni d'une contrainte d'unicité, SQL Server à
créé un index sans vous le dire. Dans les cas de PRIMARY KEY et UNIQUE
CONSTRAINT SQL Server (comme Oracle ou IBM DB2) créé un index.
En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY.
C'est à vous de les mettre en place si le nombre de ligne en vaut la
chandelle.

A +


Avatar
brouardf
Laurent a écrit :
Bonjour,

J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne pas
mettre d'index car les temps de réponse (en consultation) sont dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi du
comment.

Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.




en complément si email est muni d'une contrainte d'unicité, SQL Server à
créé un index sans vous le dire. Dans les cas de PRIMARY KEY et UNIQUE
CONSTRAINT SQL Server (comme Oracle ou IBM DB2) créé un index.
En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY.
C'est à vous de les mettre en place si le nombre de ligne en vaut la
chandelle.

A +
Avatar
brouardf
Med Bouchenafa a écrit :
En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY.
C'est à vous de les mettre en place si le nombre de ligne en vaut la
chandelle




Il est impossible de créer une FOREIGN KEY référençant une colonne qui ne
possède pas un INDEX UNIQUE de manière directe ou indirercte
Seules les colonnes en PRIMARY KEY, UNIQUE ou possèdant un INDEX UNIQUE
peuvent être référencées




on est bien d'accord...

Une FOREIGN KEY fait référence à une clef ou une contrainte d'unicité =>
index posé sur les clef et les contraintes d'unicité. En revanche les
colonnes composant la clef étrangère ne sont pas indexées.

A +