Règle générale sur l'utilisation de l'option WITH RECOMPILE

Question

Je comprends que l’option WITH RECOMPILE force l’optimiseur à reconstruire le plan de requête des processus stockés, mais quand voudriez-vous que cela se produise?

Quelles sont certaines règles de base sur l'utilisation et la non-utilisation de l'option WITH RECOMPILE?

Quelle est la surcharge effective associée au fait de simplement le mettre sur chaque sproc?

Answer 1

Comme d'autres l'ont déjà dit, vous ne voulez pas simplement inclure WITH RECOMPILE dans chaque procédure stockée par habitude. Ce faisant, vous élimineriez l'un des principaux avantages des procédures stockées: le fait qu'il enregistre le plan de requête.

Pourquoi est-ce potentiellement un gros problème? L'élaboration d'un plan de requête est beaucoup plus intensive que la compilation de code procédural classique. Comme la syntaxe d'une instruction SQL spécifie uniquement ce que vous voulez, et non (généralement) comment l'obtenir, cela donne à la base de données une grande souplesse lors de la création du plan (c’est-à-dire les instructions pas à pas pour rassembler et modifier les données). Il y a beaucoup de & astuces & astuces " le préprocesseur de requête de base de données peut faire et les choix qu'il peut faire - quel ordre pour joindre les tables, quels index utiliser, appliquer les clauses WHERE avant ou après les jointures, etc.

Pour une instruction SELECT simple, cela ne fera peut-être pas une différence, mais pour toute requête non triviale, la base de données va passer un temps considérable (mesuré en millisecondes, par opposition aux microsecondes habituelles) pour trouver plan optimal. Pour les requêtes très complexes, il ne peut même pas garantir un plan optimal , il doit simplement utiliser des méthodes heuristiques pour élaborer un plan assez bon . Donc, en le forçant à recompiler à chaque fois, vous lui dites qu'il doit suivre ce processus encore et encore, même si le plan qu'il avait auparavant était parfaitement bon.

En fonction du fournisseur, il doit exister des déclencheurs automatiques pour la recompilation des plans de requête - par exemple, si les statistiques sur une table changent de manière significative (comme, par exemple, l'histogramme des valeurs d'une colonne donnée, réparti uniformément dans le temps, devient très asymétrique ), la base de données doit le constater et recompiler le plan. Mais en règle générale, les responsables de la mise en place d’une base de données seront plus intelligents que vous dans ce domaine.

Comme pour tout ce qui a trait aux performances, ne prenez pas de photos dans le noir; identifiez les goulots d'étranglement qui coûtent 90% de vos performances et résolvez-les d'abord.

Answer 2

Le mettre sur chaque procédure stockée n’est PAS une bonne idée, car la compilation d’un plan de requête est une opération relativement coûteuse et vous ne verrez aucun avantage à ce que les plans de requête soient mis en cache et réutilisés.

Le cas d'une clause dynamique créée dans une procédure stockée peut être traité à l'aide de sp_executesql pour exécuter TSQL plutôt que d'ajouter WITH RECOMPILE à la procédure stockée.

Une autre solution (SQL Server 2005 et ultérieur) consiste à utiliser un indicateur avec des paramètres spécifiques à l'aide de l'indicateur OPTIMIZE FOR . Cela fonctionne bien si les valeurs dans les lignes sont statiques.

SQL Server 2008 a introduit un fonctionnalité peu connue appelée" OPTIMISER POUR INCONNU ":

  

Cet indice dirige l'optimiseur de requêtes.   d'utiliser les algorithmes standard dont il dispose   toujours utilisé si aucune valeur de paramètre   avait été passé à la requête du tout.   Dans ce cas, l'optimiseur aura l'air   à toutes les données statistiques disponibles à   parvenir à une détermination de ce que le   les valeurs des variables locales utilisées pour   générer le queryplan devrait être,   au lieu de regarder le spécifique   les valeurs de paramètre qui ont été passées à   la requête de l'application.

Answer 3

L’utilisation la plus courante est lorsque vous pouvez avoir une clause WHERE dynamique dans une procédure ... vous ne voudriez pas que ce plan de requête soit compilé et enregistré pour des exécutions ultérieures car il pourrait très bien ne pas être exactement la même clause la prochaine fois que la procédure est appelée.

Answer 4

généralement une meilleure alternative à WITH RECOMPILE est OPTION (RECOMPILE) comme vous pouvez le voir sur l'explication ci-dessous, tirée de la réponse à cette question ici

  

Lorsqu'un problème de sensibilité aux paramètres est rencontré, un élément commun de   Les conseils sur les forums et les sites Q & A doivent "utiliser la recompilation". (en supposant que le   les autres options de réglage présentées précédemment ne conviennent pas). Malheureusement,   ce conseil est souvent interprété à tort comme signifiant ajouter WITH RECOMPILE   option à la procédure stockée.

     

L'utilisation de WITH RECOMPILE nous renvoie effectivement à SQL Server 2000   comportement, où toute la procédure stockée est recompilée tous les   exécution. Une meilleure alternative, sur SQL Server 2005 et versions ultérieures, consiste à:   utilisez l'indicateur de requête OPTION (RECOMPILE) uniquement sur l'instruction   souffre du problème de détection de paramètre. Cet indice de requête résulte   dans une recompilation de la déclaration problématique seulement; plans d'exécution   pour les autres instructions de la procédure stockée mises en cache et réutilisées   comme d'habitude.

     

Utiliser WITH RECOMPILE signifie également que le plan compilé pour le   procédure n'est pas mis en cache. En conséquence, aucune information de performance n’est disponible.   maintenus dans des DMV tels que sys.dm_exec_query_stats. Utiliser la requête   indice signifie à la place qu’un plan compilé peut être mis en cache et que les performances   les informations sont disponibles dans les DMV (bien qu’elles soient limitées aux plus   exécution récente, pour la déclaration concernée uniquement).

     

Pour les instances exécutant au moins SQL Server 2008 build 2746 (Service   Pack 1 avec Cumulative Update 5), l’utilisation de OPTION (RECOMPILE) a un autre   avantage significatif par rapport à WITH RECOMPILE: uniquement OPTION (RECOMPILE)   active l'optimisation d'intégration de paramètres.

Answer 5

Il ne doit être utilisé que lors de tests avec des données représentatives et lorsque le contexte montre que le fait de ne pas en produire génère des plans de requête non valides (quelles que soient les raisons possibles). Ne supposez pas au préalable (sans test) qu'un SP n'optimisera pas correctement.

Une seule exception pour l’appel manuel uniquement (c’est-à-dire, ne le codez pas dans le SP): lorsque vous savez que vous avez considérablement modifié le caractère des tables cible. par exemple. TRUNCATE, chargements en vrac, etc.

C'est encore une autre opportunité d'optimisation prématurée.

Remarque: j'ai beaucoup de points. Si un nouveau participant soumet la même réponse ci-dessous et que vous acceptez, augmentez son vote.