Discussion :

[Papy214]

Bonjour

J'aimerais avoir des précisions sur la logique d'utilisation des index par MySQL. Je m'explique.
Je travaille actuellement sur une application qui utilise des fichiers DBase.
Les fichiers DBF sont associés chacun à de nombreux index basés sur des "expressions" composées de plusieurs champs.
La version actuelle du programme utilise ces index principalement pour faire des sélections de plages d'enregistrements, simplement parce que le développeur précédent ne savait pas faire un "select ...where..." et order by encore moins.

J'ai acheté et lu et de bout en bout le livre de Stéphane Combaudon et je crois avoir compris quelque chose mais ... les avis des spécialistes ici confirmeront ou pas ma compréhension de la chose.
Donc, je vois 2 cas:

Cas 1 : je fais un index composé de 3 champs C1, C2, C3 sur la table truc. MySQL l'utilise tel quel si j'ouvre la table dans mon le logiciel en utilisant cet index..

Cas 2: je fais 3 index, le premier sur C1, le second sur C2, le troisième sur C3. Je fais une requête

Code :

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

select * from truc where C1 = 1 and C2 = 3 and C3 = 12 orber by C1, C2, C3

Si j'ai compris, les 3 index seront utilisés comme un seul index composé et le résultat sera le même.


Alors question: j'ai bon ou pas ??

[SQLpro]

Lisez l'article que j'ai écrit à ce sujet :
https://sqlpro.developpez.com/cours/quoi-indexer/

A +

[escartefigue]

Cas 2: je fais 3 index, le premier sur C1, le second sur C2, le troisième sur C3.
Je fais une requête

Code :

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

select * from truc where C1 = 1 and C2 = 3 and C3 = 12 orber by C1, C2, C3

Si j'ai compris, les 3 index seront utilisés comme un seul index composé et le résultat sera le même.


Alors question: j'ai bon ou pas ??

Imaginez que vous ayez un annuaire téléphonique des particuliers avec un index portant sur les noms de famille seuls et un autre index portant sur les prénoms seuls, sans le département ni la ville.
Si vous recherchez M. Durand Stéphane habitant à Paris XV^e, comment allez vous procéder ?
Soit vous utilisez le 1er index sur le nom, puis vous parcourez séquentiellement toutes les pages pour tomber vérifier, un par un, si c'est le bon prénom, le bon département et la bonne ville.
Soit vous utilisez l'index sur le prénom, puis là encore, il faut vérifier si c'est le bon département, la bonne ville et le bon nom de famille.
Pour trouver directement Stéphane Durand dans la bonne ville et le bon département il faut disposer d'un index portant sur Département, Ville, Nom ET Prénom.

Avec un index SQL, c'est la même chose.
Donc non, le résultat avec un index sur C1, C2 et C3 ou avec 3 index distincts ne sera pas le même.

[Papy214]

Lisez l'article que j'ai écrit à ce sujet :
https://sqlpro.developpez.com/cours/quoi-indexer/

A +

Alors j'ai tout lu mais pas finalement pas si évident de savoir quand il faut créer un index ou pas, comment le composer, etc.
Je comprends par exemple qu'un index couvrant est parfois plus efficace mais il faut que ça soit réfléchi.
Mettre en premier la colonne avec le plus forte dispersion, je n'y avais pas pensé et pourtant c'est logique.

Après, il est mentionné que toutes ces explications sont pour la majorité des SGBDR mais je suis concerné par MySQL principalement.
Est-ce tout est valable pour mon cas ou dois-je faire le tri ?

Et la principale chose (la plus importante en fait) que j'ai apprise, c'est qu'une simple select ne remplace pas un index.
Je développe en Delphi avec les vieilles habitudes des TTable sur lesquels on définit un index. J'ai toujours pensé bêtement qu'une requête fesait la même chose sans index. Ok, je sors

Conclusion j'ai encore beaucoup à apprendre.

[Papy214]

@escartefigue

Je comprends mieux la problématique.
Évidemment, je sais qu'un index améliore les recherches dans une base mais je n'avais jamais poussé la réflexion aussi loin.
Le vieux logiciel que je tente de faire évoluer utilise une méthode basique d'ouverture de table, définition d'un index, application de l'index en fonction de différentes valeurs. Le SQL était totalement absent. J'ai conscience que je ne pourrai pas toujours remettre à plat mais déjà, passer de DBase à MySQL sera un grand pas. L'ancien développeur créait un index sur une table à chaque fois qu'il voulait faire un tri ou même simplement retrouver un enregistrement précis dans une table. Pour retrouver une ligne d'un client dans une tables clients, il faisait un index sur la colonne nomclient, puis ouvrait la table, appliquait l'index en indiquant comme plage de filtre le nom du client. Donc, à chaque fois, ouverture de la table, récupération de toutes les lignes, recherche par l'index, fermeture de la table. Les performances sont désastreuses mais surtout le code source est une montagne de choses inutiles avec des copier-coller de code un peu partout. J'ai l'impression chaque jour de m'attaquer à Méduse avec tous ses serpents en guise de chevelure

Comme je le disais plus haut, côté SQL j'ai encore beaucoup de choses à apprendre. Heureusement que j'aime ça

Merci pour la réponse