5
1.2 Faut-il tout optimiser ?
tée, pérenne. Souvent, les problèmes non résolus à la racine s’accumulent pour provoquer une sorte de situation d’urgence permanente où toute l’attention des
techniciens est portée à la résolution en temps réel des problèmes, comme des médecins urgentistes. En optimisation, il faut savoir différer l’administration du médicament, pour s’assurer de bien comprendre la cause. Il est indispensable de prendre du
recul, et ne pas travailler dans la précipitation. Cette recherche de la cause se fait
nécessairement à chaud, lorsque le système souffre de lenteur, tout comme un médecin ne peut identifier une maladie qu’en auscultant le patient lorsqu’il est souffrant,
et pas après sa guérison. Elle peut prendre un peu de temps, mais cette période douloureuse permettra d’en éviter bien d’autres plus tard.
1.2 FAUT-IL TOUT OPTIMISER ?
Faut-il privilégier exclusivement les performances par rapport à tout autre critère ?
Évidemment non. Il est important de maintenir un équilibre entre simplicité, lisibilité et performance. L’optimiseur de requête de SQL Server est un des meilleurs du
marché, et accomplit en général un excellent travail. Il est souvent inutile de suroptimiser vos requêtes, spécialement quand, d’une syntaxe à l’autre, le plan de
requête généré par l’optimiseur est identique. De même, l’optimisation ne doit pas
devenir une obsession, car dans ce cas, le temps qui lui est dédié peut devenir
exagéré. Ici comme ailleurs, la loi de Pareto s’applique : 20 % des efforts d’optimisation bien choisis permettent 80 % des gains de performance. Les 80 % restants
peuvent coûter beaucoup d’effort sans générer de résultats proportionnels.
Prenons un exemple. La collation détermine pour un serveur ou une base de donnée, l’ordre de classement des colonnes de type chaîne de caractères. Le choix d’une
collation a un impact sur les performances de requêtes lorsqu’elles effectuent des
comparaisons ou des recherches de chaînes. Une collation sensible à la casse, ou plus
forte encore – de type binaire par exemple – améliore la rapidité de ces requêtes, car
la comparaison de chaîne peut s’effectuer directement sur les octets sans avoir besoin
d’utiliser une table d’équivalences. C’est donc un chemin d’optimisation possible,
mais le jeu en vaut-il la chandelle, en sachant les contraintes fonctionnelles que cela
implique ? Dans une base de données en collation binaire, non seulement toutes les
requêtes devront mentionner le nom de tous les objets (tables, colonnes…) avec la
casse correcte, mais toutes les recherches de chaînes de caractères sur les colonnes
dans cette collation seront sensibles à la casse. Êtes-vous prêt à supporter ce surplus
de contrainte pour une optimisation de performance certes intéressante mais pas
toujours vitale ? C’est un équilibre qu’il vous appartient de juger.
1.2 Faut-il tout optimiser ?
tée, pérenne. Souvent, les problèmes non résolus à la racine s’accumulent pour provoquer une sorte de situation d’urgence permanente où toute l’attention des
techniciens est portée à la résolution en temps réel des problèmes, comme des médecins urgentistes. En optimisation, il faut savoir différer l’administration du médicament, pour s’assurer de bien comprendre la cause. Il est indispensable de prendre du
recul, et ne pas travailler dans la précipitation. Cette recherche de la cause se fait
nécessairement à chaud, lorsque le système souffre de lenteur, tout comme un médecin ne peut identifier une maladie qu’en auscultant le patient lorsqu’il est souffrant,
et pas après sa guérison. Elle peut prendre un peu de temps, mais cette période douloureuse permettra d’en éviter bien d’autres plus tard.
1.2 FAUT-IL TOUT OPTIMISER ?
Faut-il privilégier exclusivement les performances par rapport à tout autre critère ?
Évidemment non. Il est important de maintenir un équilibre entre simplicité, lisibilité et performance. L’optimiseur de requête de SQL Server est un des meilleurs du
marché, et accomplit en général un excellent travail. Il est souvent inutile de suroptimiser vos requêtes, spécialement quand, d’une syntaxe à l’autre, le plan de
requête généré par l’optimiseur est identique. De même, l’optimisation ne doit pas
devenir une obsession, car dans ce cas, le temps qui lui est dédié peut devenir
exagéré. Ici comme ailleurs, la loi de Pareto s’applique : 20 % des efforts d’optimisation bien choisis permettent 80 % des gains de performance. Les 80 % restants
peuvent coûter beaucoup d’effort sans générer de résultats proportionnels.
Prenons un exemple. La collation détermine pour un serveur ou une base de donnée, l’ordre de classement des colonnes de type chaîne de caractères. Le choix d’une
collation a un impact sur les performances de requêtes lorsqu’elles effectuent des
comparaisons ou des recherches de chaînes. Une collation sensible à la casse, ou plus
forte encore – de type binaire par exemple – améliore la rapidité de ces requêtes, car
la comparaison de chaîne peut s’effectuer directement sur les octets sans avoir besoin
d’utiliser une table d’équivalences. C’est donc un chemin d’optimisation possible,
mais le jeu en vaut-il la chandelle, en sachant les contraintes fonctionnelles que cela
implique ? Dans une base de données en collation binaire, non seulement toutes les
requêtes devront mentionner le nom de tous les objets (tables, colonnes…) avec la
casse correcte, mais toutes les recherches de chaînes de caractères sur les colonnes
dans cette collation seront sensibles à la casse. Êtes-vous prêt à supporter ce surplus
de contrainte pour une optimisation de performance certes intéressante mais pas
toujours vitale ? C’est un équilibre qu’il vous appartient de juger.