Quel est l'impact du reniflage des paramètres sur les performances des procédures stockées et comment peut-il être atténué ?

Impact du reniflage de paramètres sur les performances des procédures stockées

Une procédure stockée qui exploite un paramètre de date (@MyDate) présente des écarts de performances importants en fonction de la valeur initiale du paramètre lors de la compilation. Lorsque @MyDate est initialement transmis comme NULL, les exécutions ultérieures de la procédure souffrent de performances médiocres, quelle que soit la valeur d'entrée réelle. Cependant, l'initialisation de @MyDate avec une date ou la date actuelle lors de la compilation garantit des performances optimales pour tous les invocations ultérieures.

Ce comportement peut être attribué au mécanisme de détection des paramètres de SQL Server, qui évalue les valeurs des paramètres de requête lors du stockage. compilation de procédures. Dans ce cas, lorsque @MyDate est initialement NULL, l'optimiseur génère un plan d'exécution inefficace qui persiste même lorsque @MyDate contient des valeurs non NULL ultérieurement.

Pour résoudre ce problème, désactivez la détection des paramètres en utilisant une copie de le paramètre @MyDate (@MyDate_Copy). Cela garantit que SQL Server optimise le plan de requête en fonction de la valeur actuelle de @MyDate au moment de l'exécution, éliminant ainsi l'impact de la valeur initiale du paramètre.

Dans SQL Server 2005, le reniflage de paramètres est connu pour présenter de graves bugs, conduisant à des goulots d’étranglement dans les performances et même à la non-achèvement des requêtes. Par conséquent, il est recommandé de masquer les paramètres des procédures stockées pour éviter ces problèmes. SQL Server 2008 fournit la clause OPTIMIZE FOR UNKNOWN, qui peut être utilisée pour résoudre les problèmes de performances liés au reniflage de paramètres.

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!