Modo corretto per gestire 'opzionale' dove la clausola filtra in SQL?

Question

Supponiamo che tu abbia una stored procedure e che abbia un parametro opzionale. Si desidera utilizzare questo parametro facoltativo nella query SQL. In genere questo è come ho visto fare:

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

Questo sembra funzionare bene, tuttavia provoca una quantità elevata di letture logiche se si esegue la query con STATISTICS IO ON. Ho anche provato la seguente variante:

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

E produce lo stesso numero di letture alte. Se convertiamo lo SQL in una stringa, quindi chiamare sp_executesql su di esso, le letture sono quasi nulle:

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 

Sono pazzo? Perché le clausole opzionali sono così difficili da ottenere?

Aggiornamento: Sto praticamente chiedendo se c'è un modo per mantenere la sintassi standard all'interno di una stored procedure e ottenere letture logiche basse, come fa il metodo sp_ExecuteSql. Mi sembra completamente pazzo costruire una stringa ... per non parlare rende più difficile mantenere, eseguire il debug, visualizzare ..

Answer 1

Stai usando la clausola "OR" (implicitamente ed esplicitamente) sui primi due Istruzioni SQL. L'ultimo è un criterio "AND". "OR" è sempre più costoso dei criteri "AND". No, non sei pazzo, dovrebbe essere previsto.

Answer 2

Questa è un'altra variante della tecnica parametro opzionale:

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

Sono abbastanza sicuro che avrà lo stesso problema di prestazioni però. Se la performance è # 1, probabilmente rimarrai bloccato con la logica di fork e con la duplicazione di query o stringhe che è altrettanto doloroso in TSQL.

Answer 3

Se convertiamo lo SQL in una stringa, quindi chiamare sp_executesql su di essa, la legge sono quasi nullo ...

1. Perché la query non è più la valutazione di un OR, che come può vedere uccide sargability
2. Il piano di query viene memorizzato nella cache quando si utilizza sp_executesql; SQL Server non ha bisogno di fare un parse difficile ...

eccellente risorsa: The Curse & Blessing of Dynamic SQL

Finché si utilizza query con parametri, si dovrebbe al sicuro da SQL Injection attacks.

Answer 4

EDIT: Aggiunta di link to similar question/answer with context as to why the union/if...else approach works better than OR logic (FYI, Remus, ha risposto in questo link, abituato a lavorare sul team di SQL Server di sviluppo broker di servizio e altre tecnologie)

Cambio di utilizzare il "o" sintassi per un approccio unione , vedrete 2 cerca che dovrebbe tenere contano più basso possibile la vostra lettura logica:

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 

Se si vuole de-duplicare i risultati, utilizzare una "unione" invece di "unione tutti".

EDIT: Demo dimostrando che l'ottimizzatore è abbastanza intelligente per escludere la scansione con un valore variabile null in 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

Cambio di utilizzare il "o" sintassi per un approccio in due query, è ll vedi 2 piani diversi che dovrebbero mantenere il valore del tuo lettura logica il più basso possibile:

IF @MyOptionalParam is null 
BEGIN 

    SELECT * 
    FROM dbo.MyTableName t1 

END 
ELSE 
BEGIN 

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

END 

Hai bisogno di combattere stimolo del programmatore per ridurre la duplicazione qui. Renditi conto che stai chiedendo due piani di esecuzione fondamentalmente diversi e richiedi due query per produrre due piani.