Plus vous optimisez, plus votre code devient complexe. Plus il est complexe, plus il est lent. C'est le paradoxe de la performance — et il est plus fréquent qu'on ne pense.
L'optimisation qui ralentit
Scénario réel : une requête SQL met 2 secondes. Le développeur optimise. Il ajoute un index. Il réécrit la requête. Il ajoute un cache. Il partitionne la table. Résultat : la requête met 1.8 secondes. Gain : 200ms. Coût : 3 jours de développement, un schéma plus complexe, et un cache qui doit être invalidé.
Mais l'histoire ne s'arrête pas là. Trois mois plus tard, un autre développeur travaille sur une requête qui joint la table optimisée. L'index supplémentaire ralentit ses INSERTs. Le cache introduit des incohérences. Le partitionnement complique les requêtes analytiques. Le coût total de l'optimisation dépasse largement le gain initial.
La règle des 80/20 appliquée à la performance
80% des problèmes de performance viennent de 20% du code. La bonne stratégie : identifier ces 20% et les optimiser. Laisser les 80% restants tranquilles.
Mais en pratique, les développeurs optimisent ce qu'ils comprennent, pas ce qui est lent. Ils optimisent la requête qu'ils connaissent, pas la requête qui est dans le top 10 des slow queries. Résultat : ils optimisent le mauvais truc.
Quand ne PAS optimiser
1. Quand la requête n'est pas dans le top 10 des slow queries. Si elle n'est pas lente, ne la touchez pas.
2. Quand le gain est inférieur à 100ms. L'utilisateur ne percevra pas la différence. Le coût de maintenance de l'optimisation dépassera le gain.
3. Quand l'optimisation ajoute de la complexité. Si l'optimisation nécessite un trigger, un job, un cache, ou une table supplémentaire, le coût de maintenance est supérieur au gain.
4. Quand l'optimisation réduit la lisibilité. Une requête optimisée illisible est un bug futur. Un développeur la modifiera mal, et le bug coûtera plus que l'optimisation n'a économisé.
La vraie optimisation : la simplicité
La meilleure optimisation est souvent la suppression de code. Supprimer un index inutilisé accélère les INSERTs. Supprimer un trigger supprime un point de défaillance. Supprimer une table intermédiaire simplifie les requêtes.
La simplicité est la meilleure optimisation. Un code simple est facile à comprendre, facile à maintenir, et souvent plus rapide qu'un code "optimisé" complexe.
Quand optimiser
Optimisez quand :
- La requête est dans le top 10 des slow queries.
- Le gain est supérieur à 500ms.
- L'optimisation n'ajoute pas de complexité (ex : ajout d'un index simple).
- L'optimisation est mesurable et réversible.
Avant d'optimiser, mesurez. Après avoir optimisé, mesurez encore. Si l'optimisation n'apporte pas le gain attendu, revenez en arrière. Ne gardez pas une optimisation qui ne sert à rien — c'est de la dette technique.
Le paradoxe de la performance : moins vous optimisez, plus votre système est rapide. Parce que la simplicité est la meilleure optimisation.
Et vous ?
Vous optimisez sans mesure ? Aprilium audite vos bases SQL Server et identifie les 20% de requêtes qui causent 80% des problèmes. Optimisez ce qui compte, laissez le reste.
Auditer mes performances