Une bonne façon de gérer 'facultatif' où les filtres clause clause dans SQL?

Question

Supposons que vous ayez une procédure stockée et qu'elle prenne un paramètre facultatif. Vous souhaitez utiliser ce paramètre facultatif dans la requête SQL. En général, c'est ainsi que je l'ai vu faire:

SELECT * FROM dbo.MyTableName t1 
WHERE t1.ThisField = 'test' 
AND (@MyOptionalParam IS NULL OR t1.MyField = @MyOptionalParam) 

Cela semble bien fonctionner, mais il provoque une grande quantité de lectures logiques si vous exécutez la requête avec STATISTIQUES IO. J'ai également essayé la variante suivante:

SELECT * FROM dbo.MyTableName t1 
WHERE t1.ThisField = 'test' 
AND t1.MyField = CASE WHEN @MyOptionalParam IS NULL THEN t1.MyField ELSE @MyOptionalParam END 

Et il donne le même nombre de lectures élevées. Si nous convertissons le SQL à une chaîne, puis appelez sp_executesql à ce sujet, les lectures sont presque nulles:

DECLARE @sql nvarchar(max) 

SELECT @sql = 'SELECT * FROM dbo.MyTableName t1 
WHERE t1.ThisField = ''test''' 

IF @MyOptionalParam IS NOT NULL 
BEGIN 
    SELECT @sql = @sql + ' AND t1.MyField = @MyOptionalParam ' 
END 

EXECUTE sp_ExecuteSQL @sql, N'@MyOptionalParam', @MyOptionalParam 

Suis-je fou? Pourquoi les clauses facultatives sont-elles si difficiles à obtenir?

Mise à jour: Je demande essentiellement s'il existe un moyen de conserver la syntaxe standard dans une procédure stockée et d'obtenir des lectures logiques faibles, comme le fait la méthode sp_ExecuteSql. Il me semble complètement fou de construire une chaîne ... sans compter que cela rend plus difficile à maintenir, déboguer, visualiser ..

Answer 1

Vous utilisez la clause "OR" (implicitement et explicitement) sur les deux premiers Instructions SQL Le dernier est un critère "ET". "OU" est toujours plus cher que "ET" critères. Non, vous n'êtes pas fou, devrait être prévu.

Answer 2

C'est une autre variante de la technique de paramètre optionnel:

SELECT * FROM dbo.MyTableName t1 
WHERE t1.ThisField = 'test' 
AND t1.MyField = COALESCE(@MyOptionalParam, t1.MyField) 

Je suis sûr que ce sera le même problème de performance bien. Si la performance est n ° 1, vous serez probablement bloqué avec la logique de forking et les requêtes en double ou les chaînes de construction qui sont tout aussi douloureuses dans TSQL.

Answer 3

Si nous convertissons le SQL à une chaîne, puis appelez sp_executesql à ce sujet, les lectures sont presque nulles ...

1. Parce que votre requête n'évalue plus un OU, qui, comme vous peut voir tuer la sargabilité
2. Le plan de requête est mis en cache lors de l'utilisation de sp_executesql; SQL Server ne doit pas faire une analyse syntaxique dur ...

Excellente adresse: The Curse & Blessing of Dynamic SQL

Tant que vous utilisez des requêtes paramétrées, vous devriez en toute sécurité à partir SQL Injection attacks.

Answer 4

EDIT: Ajout link to similar question/answer with context as to why the union/if...else approach works better than OR logic (Pour votre information, Remus, le answerer dans ce lien, utilisé pour travailler sur l'équipe SQL Server développement courtier de services et d'autres technologies)

Changement d'utiliser la syntaxe « ou » à une approche syndicale , vous verrez 2 cherche qui devrait garder votre lecture logique compte aussi bas que possible:

SELECT * FROM dbo.MyTableName t1 
WHERE t1.ThisField = 'test' 
AND @MyOptionalParam IS NULL 
union all 
SELECT * FROM dbo.MyTableName t1 
WHERE t1.ThisField = 'test' 
AND t1.MyField = @MyOptionalParam 

Si vous voulez de-dupliquer les résultats, utilisez une « union » au lieu de « union tous ».

EDIT: Demo montrant que l'optimiseur est assez intelligent pour exclure de balayage avec une valeur variable nulle en UNION:

if object_id('tempdb..#data') > 0 
    drop table #data 
go 

-- Put in some data 
select top 1000000 
     cast(a.name as varchar(100)) as thisField, cast(newid() as varchar(50)) as myField 
into #data 
from sys.columns a 
cross join sys.columns b 
cross join sys.columns c; 
go 

-- Shwo count 
select count(*) from #data; 
go 

-- Index on thisField 
create clustered index ixc__blah__temp on #data (thisField); 
go 

set statistics io on; 
go 

-- Query with a null parameter value 
declare @MyOptionalParam varchar(50); 
select * 
from #data d 
where d.thisField = 'test' 
and  @MyOptionalParam is null; 
go 

-- Union query 
declare @MyOptionalParam varchar(50); 
select * 
from #data d 
where d.thisField = 'test' 
and  @MyOptionalParam is null 
union all 
select * 
from #data d 
where d.thisField = 'test' 
and  d.myField = '5D25E9F8-EA23-47EE-A954-9D290908EE3E'; 
go 

-- Union query with value 
declare @MyOptionalParam varchar(50); 
select @MyOptionalParam = '5D25E9F8-EA23-47EE-A954-9D290908EE3E' 
select * 
from #data d 
where d.thisField = 'test' 
and  @MyOptionalParam is null 
union all 
select * 
from #data d 
where d.thisField = 'test' 
and  d.myField = '5D25E9F8-EA23-47EE-A954-9D290908EE3E'; 
go 

if object_id('tempdb..#data') > 0 
    drop table #data 
go 

Answer 5

Changement d'utiliser la syntaxe « ou » à une approche à deux de requête, vous aurez voir 2 plans différents qui devraient garder votre compte de lecture logique aussi bas que possible:

IF @MyOptionalParam is null 
BEGIN 

    SELECT * 
    FROM dbo.MyTableName t1 

END 
ELSE 
BEGIN 

    SELECT * 
    FROM dbo.MyTableName t1 
    WHERE t1.MyField = @MyOptionalParam 

END 

Vous devez combattre l'envie de votre programmeur pour réduire le double emploi ici. Réalisez que vous demandez deux plans d'exécution fondamentalement différents et que vous avez besoin de deux requêtes pour produire deux plans.