Discussion :

[Nadinette]

Salut,

Il y a une question à laquelle je n'ai jamais trouvé de réponse.

Imaginons que j'ai une table contacts avec les colonnes nom et prénom.

Si je veux pouvoir chercher un contact par son nom et/ou son prénom,

Vaut-il mieux

Avoir 1 indexe qui englobe nom et prénom
Avoir 2 indexes distincts pour nom et pour prénom
Avoir 3 indexes, un qui englobe nom et prénom puis un pour nom et un pour prénom

?

D'avance merci

[Waldar]

Aucune des trois propositions.

Dans le cas que vous décrivez, un index sur (nom, prenom) puis un second index sur prenom.
Un recherche sur nom saura tirer parti du premier index.

Gardez quelque part à l'esprit qu'une recherche textuelle sera très probablement plus efficace pour ce genre de requête, mais c'est un autre sujet.

[escartefigue]

Dans le cas que vous décrivez, un index sur (nom, prenom) puis un second index sur prenom.

Ou plutôt :
- Un premier index sur Nom+Prénom
- Un deuxième sur Prénom+Nom

Si l'une des 2 recherche est très fréquente, alors l'index correspondant pourra être choisi comme index cluster afin de balayer facilement les homonymes

[Nadinette]

merci

[SQLpro]

Aucune des trois propositions.

Dans le cas que vous décrivez, un index sur (nom, prenom) puis un second index sur prenom.
Un recherche sur nom saura tirer parti du premier index.

Pas d'accord !

Ou plutôt :
- Un premier index sur Nom+Prénom
- Un deuxième sur Prénom+Nom

Si l'une des 2 recherche est très fréquente, alors l'index correspondant pourra être choisi comme index cluster afin de balayer facilement les homonymes

Pas mieux !

Tout dépend du type d'index disponible dans le SGBD visé et de la qualité de l'optimiseur !

Si indexation de ligne (indexation dite "horizontale", par exemple index BTree) alors deux index l'un sur le nom et l'autre sur le prénom peuvent être utilisés. C'est le cas de SQL Server. Voir exemple :


Dans ce cas toutes les combinaisons de recherches sont possibles :

• nom seul
• prenom seul
• nom + prenom dans n'importe quel ordre

Si l'indexation est de type verticale 'Columnstore par exemple) alors un seul index combinant non et prénom peut être utilisé quelque soit la recherche. C'est aussi le cas de SQL Server. Voir 2e exemple :


Évidemment, si vous utilisé un pseudo SGBDR comme MySQmerde, il n'y a aucune chance que ce type d'index et cette optimisation qui consiste à utiliser deux index soit disponible !!! MySQL en est à l'âge de pierre...


A +

[Nadinette]

Merci à tous, il semble au moins que tout le monde ne soit pas d'accord, la question méritait d'être posée
Sinon, c'est à partir de combien de lignes qu'un indexe commence à devenir indispensable.
On m'a dit que s'il n'y avait pas beaucoup de lignes c'était pénalisant.

[escartefigue]

Si l'indexation est de type verticale 'Columnstore par exemple) alors un seul index combinant non et prénom peut être utilisé quelque soit la recherche. C'est aussi le cas de SQL Server.

C'est loin d'être le cas de tous les SGBD ! (et pas seulement MySQL)

[SQLpro]

On m'a dit que s'il n'y avait pas beaucoup de lignes c'était pénalisant.

Tout à fait... mais aucun intérêt.

Si vous avez 10 lignes dans une table et que la lecture de 10 lignes met 0.00000001 seconde, alors avec un index cela mettra 0.00000002 secondes avec un index (le double !!!) et en sus vos mises à jours (INSERT, UPDATE, DELETE) vont mettre 10 à 20% de temps en plus...
Tout ceci n'ayant aucune importance parce que ces temps sont en fait impossible à mesurer tellement ils sont infime !

MAIS....

Si vous ne mettez pas vos index dès le départ et que votre table grossit pour une raison ou une autre (rachat, fusion...) alors là vous risquez d'avoir des temps de réponse catastrophiques.

MORALITÉ : mettez tous les index nécessaire sur toutes les tables, petites ou grosses.
Sur les petites tables, la pénalité est infime et non mesurable, mais si vous l'oubliez et qu'elle devient grosse ... c'est le drame !

A +