Discussion :

[usf70]

Bonjour,

Je me tourne vers vous car il y a un comportement de SQL Server que je ne comprends pas.
Nous avons créé une procédure stockée qui est définie comme suit:

CREATE PROCEDURE [dbo].[ma_proc]
(
@variable int
)
AS
SET NOCOUNT ON;
Select
*
From
ma_table
Where
(champs1 = @variable Or @variable is null)
GO

la table ma_table possède une clé primaire (donc clustered) sur le champs1 (et uniquement ce champs là), mais aussi un index non clustered sur un champs2.
Lorsque je regarde le plan d'exécution de la procédure stockée, il fait un index scan en utilisant l'index non clustered sur le champs2 (??? pourquoi ???), alors que si je prend la requête SQL et que je regarde directement le plan d'exécution de celle-ci, il me fait bien un index seek sur la clé primaire positionnée sur le champs1.

Ce n'est pas un problème de statistiques, car je les recalcule et il fait pareil ...
Quelqu'un aurait une explication ???

[ZERS]

Salut,

rien à voir avec ta question (quoi que ?) mais je ne comprends pas ce test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
(champs1 = @variable Or @variable is null)

[usf70]

ouais .. tu as raison, je ne suis pas très clair sur le titre. En fait, je voulais parler de la différence entre utiliser la requête SQL directement ou encapsulée dans une SP.
La procédure stockée est lancée de cette manière :

exec ma_proc @variable = xxxxx

où les xxxxx est un chiffre. Pour ce qui est du test, je reprends cette proc d'un autre programmeur .... J'ai aussi posé la question mais je n'ai pas eu de réponse. Tu penses que ça aurait une incidence sur l'utilisation ou non du bon index ? Selon que l'on teste la SP ou directement la requête SQL ?

[ZERS]

ouais .. tu as raison, je ne suis pas très clair sur le titre. En fait, je voulais parler de la différence entre utiliser la requête SQL directement ou encapsulée dans une SP.

si si la question était très claire t'inquiète

Pour ce qui est du test, je reprends cette proc d'un autre programmeur .... J'ai aussi posé la question mais je n'ai pas eu de réponse. Tu penses que ça aurait une incidence sur l'utilisation ou non du bon index ? Selon que l'on teste la SP ou directement la requête SQL ?

Ben si tu veux si on traduit en français la requete ca veut dire :
"donne moi toutes les clonnes de matables pour lequelles le champs1 est égale à la valeur ou valeur = null".

Bref ca veut rien dire... A moins que les connaissances SQL ne me permettent pas de comprendre une telle syntaxe.

Si il voulait dire :
"si valeur est null, on renvoie tout, ou sinon, on renvoie uniquement les lignes pour lesquels champs1= valeur non nulle", ben j'aurais pas du tout écris cela comme cela...

Du coup, oui cela peut avoir une incidence sur le moteur sql.

[usf70]

J'ai trouvé cette page sur le site de microsoft:

http://msdn2.microsoft.com/fr-fr/library/ms190439.aspx

qui explique que si on a modifié une table qui est utilisée par une procédure stockée (rajout d'un index par exemple), la SP ne vera pas la modification, sauf si on la recompile. En fait, elle conserve son plan d'exécution initial tant qu'elle n'a pas été recompilée.

Serait-ce ça mon problème ???

[usf70]

OK, j'ai réussi à cerner le problème. Et ZERS avait raison. C'est bien le test

@variable is null

qui fausse le plan d'exécution.
J'ai remplacé ma SP par :

CREATE PROCEDURE [dbo].[ma_proc] with RECOMPILE
(
@variable int
)
AS
SET NOCOUNT ON;
if @variable is null
begin
Select * From ma_table
end
else
begin
Select * From ma_table Where (champs1 = @variable)
end

Et là, c'est OK. Merci de ton aide ZERS.