b) Optimiser les jointures

Les jointures constituent une construction du langage puissante, mais à manier avec précaution, car une jointure proprement ratée peut facilement mettre à genoux un serveur de bases de données.

Concrètement, une jointure entre une requête qui remonte 200 enregistrements et une autre qui en remonte 300 retourne 200*300 soit 60 000 enregistrements. En général à partir de ce moment-là, MySQL est contraint d'utiliser une table temporaire, et c'est le début de la Bérézina en termes de performances.

Sachez tout d'abord les utiliser avec discernement, car une jointure n'est pas toujours indispensable. Prenons l'exemple d'une base contenant 60 000 clients. Chaque client peut avoir un ou plusieurs comptes bancaires, avec pour chaque compte différentes informations associées telles que date d'ouverture et montant des dépôts. Est-il logique de faire une jointure entre ces deux tables ? N'est-il pas plus efficace de faire une première requête sur les comptes, puis de les associer aux enregistrements des clients sur le serveur applicatif, en fonction de l'id du client ?

Si malgré tout l'utilisation d'une jointure est impérative, écrivez-la dans les règles de l'art. Utilisez notamment les mots-clés de jointure, au lieu d'utiliser des clauses WHERE. Certes, l'écriture de la jointure dans le WHERE ou dans le JOIN est équivalente. Mais la seconde a plusieurs avantages :

• cette écriture supprime le risque d'oublier les ou l'une des conditions de jointure
• elle est plus lisible pour le mainteneur, car la jointure est immédiatement visible et identifiable.

Une utilisation judicieuse de l'indexation est stratégique pour l'exécution rapide d'une requête avec jointure.