Mauvaises performances des procédures stockées en raison du reniflage des paramètres
Vous rencontrez des problèmes de performances avec une procédure stockée dans laquelle un paramètre d'entrée (@MyDate) peut être NULL ou une date. Lorsque la procédure est compilée pour la première fois avec @MyDate comme NULL, les exécutions ultérieures présentent des performances médiocres quelle que soit la valeur réelle du paramètre.
Comportement de reniflage des paramètres
SQL Server exécute "le paramètre sniffing" pour optimiser les plans d'exécution en fonction des valeurs des paramètres lors de la compilation. Il capture ces valeurs dans le cache de procédure et les utilise pour estimer les exécutions futures.
Dans ce cas, le reniflage de paramètres est à l'origine du problème car il génère un plan d'exécution sous-optimal pour toutes les valeurs de paramètre lorsque @MyDate est initialement NULL. Même lorsque @MyDate est explicitement défini sur NULL au moment de l'exécution, le plan mis en cache reste.
Désactivation du reniflage des paramètres
Vous avez rencontré le symptôme classique du « reniflage des paramètres » qui a mal tourné", où le plan généré pour les valeurs initiales des paramètres est utilisé même lorsqu'elles ne sont pas représentatives des exécutions réelles. Pour désactiver la détection des paramètres, vous avez usurpé le paramètre avec @MyDate_Copy.
Cause fondamentale et solution
Le problème provient d'un bug de SQL Server 2005 dans lequel la détection des paramètres peut mal se comporter. Dans SQL Server 2008, vous pouvez atténuer ce problème en utilisant l'option OPTIMIZE FOR UNKNOWN, qui oblige l'optimiseur à prendre en compte toutes les valeurs possibles pour le paramètre lors de la compilation du plan.
Informations supplémentaires
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!