Statistiques SQL Server et estimation de cardinalité

L'optimiseur choisit jointures, accès et mémoire selon le nombre de lignes estimé. Un écart important avec la réalité peut rendre un plan raisonnable très coûteux.

Pourquoi ce sujet exige une attention méthodique

Un problème de ce type existe rarement seul. Une modification qui améliore une requête peut augmenter les écritures, le journal, les blocages, la reprise ou la complexité ailleurs. Traitez le travail comme une décision d'ingénierie avec un objectif mesurable, des contraintes connues et un responsable.

La maintenance doit suivre l'évolution des données et la sensibilité de la charge, pas un calendrier universel.

Ce qu'il faut mesurer

Comparez lignes estimées et réelles au premier opérateur significatif. Examinez histogramme, modifications, échantillonnage, clés croissantes, prédicats corrélés et expressions masquant les colonnes.

Méthode de diagnostic

• Définissez précisément symptôme, charge touchée, début, fréquence et impact visible.
• Collectez des preuves pendant les périodes normales et dégradées pour la même opération métier.
• Séparez corrélation et cause en examinant plans, attentes, ressources, blocages, configuration et changements récents.
• Testez des groupes représentatifs de bases, requêtes ou paramètres, pas seulement le cas le plus simple.
• Conservez réglage, plan, définition d'objet et compteurs actuels avant toute modification.
• Exprimez numériquement le résultat attendu : latence, CPU, lectures logiques, débit, file ou temps de reprise.

Choisir l'intervention

Préférez le changement le plus limité qui traite la cause démontrée. Une configuration serveur touche de nombreuses charges, tandis qu'une modification de requête, index, statistique ou horaire peut être ciblée. Considérez licence, version SQL Server, haute disponibilité, fenêtres de maintenance et capacité de surveillance.

Approche pratique

Gardez les statistiques automatiques, actualisez les statistiques importantes après des changements significatifs, utilisez des statistiques filtrées ou multicolonnes pour les distributions particulières et réécrivez les prédicats opaques.

Séquence de mise en œuvre sûre

• Reproduisez le comportement dans un environnement sûr avec un volume proche de la production.
• Modifiez une variable importante à la fois et conservez la définition d'origine pour le retour arrière.
• Mesurez durée, CPU, lectures, écritures, attentes, mémoire, journal et effets en aval.
• Testez entrées normales, pics et cas limites, ainsi que redémarrage ou basculement si nécessaire.
• Déployez dans une fenêtre adaptée avec opérateur, propriétaire applicatif et décideur de retour arrière disponibles.
• Évaluez immédiatement puis pendant le prochain pic représentatif de production.

Exemple SQL Server

L'exemple suivant sert de point de départ pour l'analyse ou une mise en œuvre contrôlée. Adaptez bases, seuils, rétention et autorisations avant la production. Conservez la sortie avec la chronologie de l'incident au lieu de considérer un seul échantillon comme un diagnostic complet.

SELECT
    s.name AS statistics_name,
    sp.last_updated,
    sp.rows,
    sp.rows_sampled,
    sp.modification_counter,
    sp.steps
FROM sys.stats AS s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) AS sp
WHERE s.object_id = OBJECT_ID(N'dbo.Orders')
ORDER BY sp.modification_counter DESC;

Ce qu'il faut éviter

Ne lancez pas FULLSCAN sur toutes les statistiques chaque nuit, ne supposez pas qu'une reconstruction actualise tout et ne masquez pas chaque erreur par un hint.

Surveillance après le changement

Surveillez la métrique visée et au moins deux effets secondaires possibles. Comparez des périodes et volumes équivalents. Observez assez longtemps pour inclure maintenance, sauvegardes, reporting, basculement et activités périodiques. Documentez si l'amélioration persiste et si le changement doit rester, évoluer ou disparaître.

Retour arrière et responsabilité

Le retour arrière doit préciser l'ancienne valeur ou définition, le décideur et le signal de déclenchement. Conservez le plan et le script d'origine pour les changements de plan ou métadonnées. Pour l'infrastructure, confirmez capacité et temps de maintenance avant de commencer.

Résultat opérationnel

La maintenance doit suivre l'évolution des données et la sensibilité de la charge, pas un calendrier universel.

Checklist de production

Établissez une référence et définissez l'amélioration attendue. Testez avec des données et une concurrence représentatives. Conservez la configuration ou le plan d'origine, préparez un retour arrière et surveillez le prochain pic normal de charge.

Questions avant de clôturer

• Le symptôme initial s'est-il amélioré sous la même charge ?
• De nouveaux coûts d'écriture, stockage, blocage, mémoire ou disponibilité sont-ils apparus ?
• Le résultat survivra-t-il au redémarrage, basculement, statistiques et croissance ?
• Les alertes détecteront-elles une régression avant les utilisateurs ?
• La décision, le responsable et la date de révision sont-ils enregistrés ?

Pour appliquer cette méthode à un environnement SQL Server précis, utilisez le formulaire ci-dessous et indiquez la version, la taille de la base, le profil de charge et les éléments déjà collectés.