Pour bien optimiser des requêtes SQL, il est nécessaire de bien comprendre ce qu’il se passe lorsque l’on exécute une requête. On verra ensuite quelques leviers simples, pour améliorer les performances de tes requêtes.
Quel est le processus d’envoi d’une requête SQL?
Pour mieux comprendre ce qui se passe lors de l’exécution d’une requête SQL, et surtout identifier où le temps est dépensé, regardons son fonctionnement.
- Envoi de la requête
- L’utilisateur envoie une requête SQL à la base de données pour demander ou modifier des informations.
- Analyse de la syntaxe
- Le système vérifie si la requête est bien formulée. Si une virgule est mal placé par exemple, il y a une erreur.
- Vérification des éléments demandés
- Le système regarde si les tables et les colonnes mentionnées existent bien.
- Optimisation du plan d’exécution
- Avant d’exécuter la requête, la base de données cherche la manière la plus rapide de le faire. En utilisant un index ou en parcourant toute une table, par exemple.
- Exécution de la requête
- La base de données effectue les opérations demandées : chercher, trier, calculer, insérer, etc.
- Envoi du résultat
- Le résultat est renvoyé : cela peut être une liste de résultats, un message de confirmation ou une simple information.
Bien sûr, il s’agit d’une version résumée et simplifiée d’un processus d’exécution d’une requête SQL. Il existe des variations en fonction du type de la base de données, mais cela permet de se faire une idée 😉.
Un exemple pour bien comprendre
Si tu souhaites exécuter la requête suivante, pour ressortir les noms des clients qui sont situés en France. Voici la requête et ses étapes d’exécution.
SELECT nom FROM clients WHERE pays='France';- Requête envoyée
- Envoi de la requête à la base de données.
- Vérification de la syntaxe
- Est-ce que la requête est bien écrite ? Les mots-clés sont-ils valides (SELECT, FROM, WHERE, etc.) ?
- Vérification des tables et colonnes
- Est-ce que la table
clientsexiste ? Est-ce qu’il y a une colonnenomet une colonnepays?
- Est-ce que la table
- Optimisation
- Le système choisit le chemin le plus rapide : par exemple, utiliser un index sur
payspour éviter de lire toute la table (si l’index existe).
- Le système choisit le chemin le plus rapide : par exemple, utiliser un index sur
- Exécution
- La base de données va chercher les données demandées.
- Résultat envoyé
- La réponse (la liste des noms des clients français) est renvoyée.
Généralement, pour des tables contenant peu de données, l’enchainement de ses étapes prendra peu de temps (quelques millisecondes).
Les actions à mettre en place pour optimiser ses requêtes SQL
La règle d’or, collecter seulement les champs nécessaires
S’il y a bien une règle n°1 pour optimiser ses requêtes SQL, c’est bien celle-ci. Ne pas sélectionner tous les champs. En effet, on peut avoir tendance à faire un SELECT *, plutôt que sélectionner uniquement les colonnes utiles. C’est souvent par facilité, donc c’est OK pour tester, mais seulement pour tester et vérifier les résultats.
SELECT * FROM clients; /* Feignantise = pas bien ❌ */
SELECT prenom, nom FROM clients; /* Précis = bien ✅ */Bien sûr, il existe des cas d’usage où on a besoin de toutes les colonnes. Dans ce cas là, on peut se permettre de tout sélectionner.
Moins de colonnes à récupérer = moins de données à récupérer (surtout sur des tables / colonnes volumineuses).
Archiver ou purger pour avoir des tables avec des tailles raisonnables
Je considère qu’une table est volumineuse à partir de + d’un million de lignes. Si une table dépasse cette taille, il est légitime de se poser la question : est-ce que j’ai besoin de toutes ces lignes ? Si oui, on va archiver des données. Et dans le cas contraire, on va simplement purger ce dont on n’a plus besoin.
Naturellement, moins une table est volumineuse, plus le temps d’exécution est rapide. Surtout si la requête doit parcourir l’ensemble de la table lors de l’execution.
Éviter de parcourir l’ensemble de la table
Pour faire un test concret, j’ai créé une table contenant 1 000 000 lignes. De cette façon, nous pourrons mesurer plus facilement l’impact et l’utilité d’un index sur une table volumineuse. La table est répartie comme cela:
- Environ 100 000 entrées avec un pays correspondant à France
- Environ 900 000 entrées avec un pays correspond à Autre
Sur cette table, nous avons uniquement un index sur la colonne id. On va donc faire une première requête en filtrant sur le pays et on fera la même en ayant créé l’index.
La requête retournera donc tout le temps ~100 000 résultats.
SELECT nom FROM clients WHERE pays = 'France'| Index existant | Type | Temps d’exécution moyen |
|---|---|---|
| Non | All | 7,5 secondes ❌ |
| Oui | Ref | 0,8 secondes ✅ |
Pour obtenir un temps d’exécution représentatif, j’ai fais une moyenne sur une dizaine d’exécutions. On voit bien ici qu’avec un index, le temps est largement amélioré ☺️ !
Pourquoi on ne créé pas d’index sur toutes les colonnes ?
Maintenant qu’on sait qu’un index améliore grandement les performances, on aurait envie de créer des index sur plusieurs colonnes. Cependant, il y a deux contraintes majeures, à créer des index:
Il faut donc trouver le bon compromis et bien sélectionner les index à créer. Travaille uniquement sur les requêtes dégradées (> à 1 seconde).
En résumé : des requêtes SQL rapides, c’est possible !
Tu sais maintenant ce qui se passe sous le capot lors de l’exécution d’une requête SQL, et surtout quels réflexes adopter pour éviter les lenteurs. Avant de valider ta requête, pense à :
- Vérifier sa structure (jointures, sous-requêtes, clauses mal optimisées).
- Exploiter les index (ou en créer si nécessaire).
- Surveiller la taille de tes tables (et leur croissance).
Avec ces bases, tu as déjà de quoi booster les performances SQL de ton application. Ce sujet t’intéresse ? Dis-le moi en commentaire : on peut creuser ensemble les optimisations avancées, les outils d’analyse, ou même des cas concrets ☺️.