Constantes TSQL ... Utiliser une variable ou une valeur littérale?

Question

Je lis juste les directives de code de mon compagnie et il dit de ne jamais traiter des variables comme une constante dans le serveur sql, employez plutôt des littéraux. Le raisonnement est que SQL Server ne peut pas construire un bon plan d'exécution lorsque vous utilisez des variables dans la requête.

Quelqu'un sait si cela est encore vrai? Nous utilisons MSSQL 2005 et ce document a peut-être été écrit pour 2000.

Answer 1

Ceci est "généralement" vrai pour SQL Server 2005 car il essaie maintenant de pré-générer des plans d'exécution pour autant de requêtes que possible. Votre kilométrage peut varier car il dépend de vos données et votre SARG (tester vos plans de requête et voir), mais ce tecdoc (ils utilisaient une version pré-version de SQL Server 2005) déclare:

http://www.microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx

Évitez d'utiliser des variables locales dans requêtes

Si vous utilisez une variable locale dans une requête prédicat au lieu d'un paramètre ou littéral, les stations de optimiseur à une estimation de qualité réduite, ou une estimation pour la sélectivité de la prédicat. Utilisez paramètres ou littéraux dans la requête au lieu de variables locales, et l'optimiseur sera généralement en mesure de choisir un meilleur plan de requête. Par exemple, considérez cette requête qui utilise une variable locale :

Answer 2

Je ne sais pas si c'est toujours vrai, mais en utilisant une variable qui ne peut pas être évaluée avant que le temps d'exécution ne limite la capacité du optimiseur pour utiliser les statistiques qu'il a collectées sur la table lors de la prise de décisions d'optimisation. L'article référencé en traite et donne quelques conseils sur la façon d'aider SQL Server à prendre ses décisions d'optimisation dans le cas où cela ne peut être évité.

Ref: http://www.sqlmag.com/Article/ArticleID/42801/sql_server_42801.html

Answer 3

SQL Server peut construire un meilleur plan d'exécution s'il utilise un littéral. Un cas que j'ai vu impliquait une vue de partion. Si vous sélectionnez dans la vue en partition avec une variable SQL évaluera la variable à l'exécution, où comme si vous utilisez un SQL littéral va juste après la table sous-jacente. Cela dit, vous devriez tester avant le codage en dur, et si vous avez deux requêtes qui ne diffèrent que par le littéral, alors ce serait une odeur.