308
Chapitre 9. Optimisation des procédures stockées
Figure 9.5 — Plusieurs plans sur des différences syntaxiques
Attention – La correspondance avec un plan ad hoc caché n’est possible que si
les objets sont préfixés par leur schéma.
Comme pour le cache de procédure, ces plans d’exécution ne sont libérés qu’en
cas de besoin mémoire.
Mais ce fonctionnement est valable même en considérant des valeurs constantes
différentes, passées dans les clauses WHERE pour la recherche ? En d’autres termes, des
requêtes comme :
SELECT * FROM Person.Contact WHERE ContactId = 20
GO
SELECT * FROM Person.Contact WHERE ContactId = 40
GO
sont-elles cachées séparément ? Cela dépend. Dans cet exemple, un examen de
sys.dm_exec_query_stats. Montre ceci :
(@1 tinyint)SELECT * FROM [Person].[Contact] WHERE [ContactId]=@1
Ce qui signifie que SQL Server a transformé la requête avant de la mettre dans le
cache, pour remplacer les valeurs littérales par un paramètre. Dans certains cas, SQL
Server peut donc « paramétrer » la requête, et transformer la valeur passée comme
critère de recherche en paramètre, en interne. Cela permet de réutiliser le plan si
d’autres paramètres sont passés. Ce mécanisme s’appelait paramétrage automatique
(auto-parameterization) en SQL Server 2000, et est maintenant nommé paramétrage
simple (simple parameterization).
Le comportement par défaut de SQL Server fait qu’un nombre limité de requêtes
peuvent être ainsi paramétrées. Par exemple, les deux requêtes suivantes sont
cachées séparément sur SQL Server 2005 sp2 :
SELECT * FROM Person.Contact WHERE LastName = 'Allen'
GO
SELECT * FROM Person.Contact WHERE LastName = 'Ackerman'
GO
Nous avons vu que la valeur de LastName peut ici fortement influencer le plan
d’exécution, déclenchant soit un seek, soit un scan de l’index. L’exemple précédent,
où le paramétrage avait eu lieu, était plus facile : ContactId est la clé primaire de la
table, donc sa valeur est garantie unique. Une recherche d’égalité est donc garantie
de retourner une seule ligne, et qui plus est dans une recherche par un index clustered
Chapitre 9. Optimisation des procédures stockées
Figure 9.5 — Plusieurs plans sur des différences syntaxiques
Attention – La correspondance avec un plan ad hoc caché n’est possible que si
les objets sont préfixés par leur schéma.
Comme pour le cache de procédure, ces plans d’exécution ne sont libérés qu’en
cas de besoin mémoire.
Mais ce fonctionnement est valable même en considérant des valeurs constantes
différentes, passées dans les clauses WHERE pour la recherche ? En d’autres termes, des
requêtes comme :
SELECT * FROM Person.Contact WHERE ContactId = 20
GO
SELECT * FROM Person.Contact WHERE ContactId = 40
GO
sont-elles cachées séparément ? Cela dépend. Dans cet exemple, un examen de
sys.dm_exec_query_stats. Montre ceci :
(@1 tinyint)SELECT * FROM [Person].[Contact] WHERE [ContactId]=@1
Ce qui signifie que SQL Server a transformé la requête avant de la mettre dans le
cache, pour remplacer les valeurs littérales par un paramètre. Dans certains cas, SQL
Server peut donc « paramétrer » la requête, et transformer la valeur passée comme
critère de recherche en paramètre, en interne. Cela permet de réutiliser le plan si
d’autres paramètres sont passés. Ce mécanisme s’appelait paramétrage automatique
(auto-parameterization) en SQL Server 2000, et est maintenant nommé paramétrage
simple (simple parameterization).
Le comportement par défaut de SQL Server fait qu’un nombre limité de requêtes
peuvent être ainsi paramétrées. Par exemple, les deux requêtes suivantes sont
cachées séparément sur SQL Server 2005 sp2 :
SELECT * FROM Person.Contact WHERE LastName = 'Allen'
GO
SELECT * FROM Person.Contact WHERE LastName = 'Ackerman'
GO
Nous avons vu que la valeur de LastName peut ici fortement influencer le plan
d’exécution, déclenchant soit un seek, soit un scan de l’index. L’exemple précédent,
où le paramétrage avait eu lieu, était plus facile : ContactId est la clé primaire de la
table, donc sa valeur est garantie unique. Une recherche d’égalité est donc garantie
de retourner une seule ligne, et qui plus est dans une recherche par un index clustered