Optimisation des bases de données SQL Server : l’exploitation

Nous avons déjà dit que les index sont une aide formidable pour optimiser les requêtes. La pose d’index entraîne la mise en place de statistiques sur les données de l’index, statistiques qui sont calculées à la création de l’index et recalculées lors de manoeuvres de remaniement d’index ou encore de manière automatique si cette option est activée. Si les index n’ont pas été recalculés depuis longtemps, alors le moteur SQL constate qu’un décalage existe entre l’échantillon sur lequel le calcul des statistiques a été fait et la réalité des données de la table.

Dès lors, le moteur SQL est en droit de considérer que ces statistiques n’ont plus d’intérêt car elles ne reflètent plus la réalité. Dans ce cas, le plan de requête est recalculé sans tenir compte des index suspects afin d’éviter d’utiliser lesdits index jugés obsolètes ! Voilà donc un premier point à surveiller : la mise à jour régulière des statistiques. Dans une base de moyenne importance, l’option automatique de mise à jour des statistiques peut s’avérer efficace, d’autant que la version 2005 de SQL Server permet de le faire de manière asynchrone. Dans de très grandes bases (VLDB) il vaut mieux planifier cela aux heures creuses.

Cependant, la seule mise à jour des statistiques n’est pas suffisante. Un index dont les données sont fortement impactées par des mises à jour (INSERT, UPDATE DELETE) peut s’avérer peu efficace en recherche. En effet, au fur et à mesure que les données évoluent, la structure de données qui stocke les index – en fait un arbre équilibré – peut se trouver en défaut : des pages peu pleines, des lignes déplacées, des lectures en zigzag… Comment cela est-il possible et comment y remédier ? Pour le remède, la chose est simple, il faut défragmenter l’index ou le reconstruire.