Un serveur plus gros est rarement la bonne réponse
Face à une base lente, le réflexe est souvent d'ajouter de la mémoire ou des cœurs. C'est coûteux, surtout avec les licences SQL Server facturées au cœur, et le gain est souvent décevant : une requête qui lit cent fois trop de pages le fera aussi sur un serveur neuf. Dans la grande majorité des cas, quelques requêtes, quelques index et quelques paramètres expliquent l'essentiel du problème.
Tuning SQL Server : notre démarche en quatre temps
- Mesurer. Statistiques d'attente, Query Store, Extended Events et compteurs système : on établit une référence chiffrée avant de toucher à quoi que ce soit.
- Isoler. Les requêtes et les objets qui consomment réellement le CPU, les lectures et le temps d'attente, classés par impact.
- Corriger. Index, statistiques, réécriture de requêtes, réglages de l'instance, niveau d'isolation. Chaque changement est testé et réversible.
- Vérifier. Comparaison avant et après sur les mêmes indicateurs. Si le gain n'est pas là, on le voit tout de suite.
Les causes que nous rencontrons le plus souvent
Indexation : des index absents, inadaptés ou en trop
Un index manquant force des parcours complets de tables volumineuses. À l'inverse, des dizaines d'index jamais lus ralentissent chaque insertion et mise à jour. Les suggestions d'index manquants de SQL Server sont un point de départ, pas une liste à appliquer telle quelle.
Des plans d'exécution instables
Le parameter sniffing fait qu'une même procédure est rapide le matin et catastrophique l'après-midi. Le Query Store permet d'identifier ces régressions et de stabiliser les plans sans modifier le code.
Des requêtes qui empêchent l'usage des index
Conversions implicites de types, fonctions appliquées aux colonnes filtrées, fonctions scalaires appelées ligne par ligne, curseurs là où une requête ensembliste suffirait. Notre DBA principal a d'ailleurs écrit sur les problèmes de performance des curseurs SQL Server pour SQLShack.
Blocages et deadlocks
Des transactions trop longues, un niveau d'isolation inadapté ou un ordre d'accès incohérent entre deux traitements suffisent à figer une application. L'isolement par versionnement (RCSI) résout beaucoup de cas, à condition de dimensionner tempdb en conséquence.
Une instance mal réglée
Mémoire maximale non plafonnée, parallélisme mal calibré, tempdb sous-dimensionnée, statistiques jamais mises à jour sur les grosses tables, latence de stockage. Ces réglages se corrigent vite et profitent à toutes les applications de l'instance.
Applications métier et progiciels
Beaucoup d'entreprises françaises font tourner sur SQL Server des logiciels dont elles ne maîtrisent pas le code : ERP et gestion commerciale (Sage 100, Sage X3, Cegid, Microsoft Dynamics), logiciels de paie ou métiers. Quand « Sage est lent » ou qu'un traitement de clôture n'en finit plus, la cause est très souvent côté base de données. On peut presque toujours les accélérer sans toucher à l'application, en travaillant sur les index, la maintenance et l'instance, et en fournissant à l'éditeur un diagnostic précis quand la correction lui revient.
Un résultat vérifiable
Une mission d'optimisation SQL Server se juge sur des chiffres. L'objectif est fixé dès le départ en termes concrets : temps d'affichage d'un écran, durée d'un traitement de nuit, consommation CPU aux heures de pointe. Vous savez ce qui a été fait, pourquoi, et ce que cela a rapporté. Si vous ne savez pas encore par où commencer, un audit SQL Server donne une vue d'ensemble avant d'entrer dans le détail.
