Buono, cattivo o indifferente: DOVE 1 = 1

Data questa domanda su reddit, ho ripulito la query per sottolineare dove si trovava il problema nella query. Uso prima la virgola e WHERE 1=1per semplificare la modifica delle query, quindi le mie query generalmente finiscono in questo modo:

SELECT 
     C.CompanyName
    ,O.ShippedDate
    ,OD.UnitPrice
    ,P.ProductName
FROM 
               Customers       as C
    INNER JOIN Orders          as O  ON C.CustomerID = O.CustomerID
    INNER JOIN [Order Details] as OD ON O.OrderID    = OD.OrderID
    INNER JOIN Products        as P  ON P.ProductID  = OD.ProductID
Where 1=1
--  AND O.ShippedDate Between '4/1/2008' And '4/30/2008'
    And P.productname = 'TOFU'
Order By C.CompanyName

Qualcuno ha sostanzialmente affermato che 1 = 1 è generalmente pigro e cattivo per le prestazioni .

Dato che non voglio "ottimizzare prematuramente", voglio seguire le buone pratiche. Ho già esaminato i piani di query in precedenza, ma in generale solo per scoprire quali indici posso aggiungere (o modificare) per rendere più veloci le mie query.

La domanda allora davvero ... fa Where 1=1accadere cose brutte? E se sì, come posso dirlo?

Modifica minore: ho sempre anche "ipotizzato" che 1=1sarebbe stato ottimizzato o, nel peggiore dei casi, trascurabile. Non fa mai male mettere in discussione un mantra, come "Goto's are Evil" o "Premature Optimization ..." o altri fatti ipotizzati. Non ero sicuro che 1=1 ANDavrebbe influenzato realisticamente i piani di query o meno. Che dire delle sottoquery? Di CTE? Procedure?

Non sono uno da ottimizzare, a meno che non sia necessario ... ma se sto facendo qualcosa di veramente "cattivo", vorrei minimizzare gli effetti o cambiare dove applicabile.

Il server SQL parserL'ottimizzatore ha una funzione chiamata "Piegatura costante" che elimina le espressioni tautologiche dalla query.
Se guardi il piano di esecuzione, da nessuna parte nei predicati vedrai apparire quell'espressione. Ciò implica che la piegatura costante viene eseguita comunque in fase di compilazione per questo e altri motivi e non ha alcun effetto sulle prestazioni della query.

Per ulteriori informazioni, consultare la valutazione della piegatura e dell'espressione costanti durante la stima della cardinalità .

L'aggiunta del predicato ridondante può fare la differenza in SQL Server.

Nei piani di esecuzione di seguito notare il @1nel primo piano contro il letterale 'foo'nel secondo piano.

Ciò indica che SQL Server ha considerato la prima query per una semplice parametrizzazione per promuovere il riutilizzo del piano di esecuzione, tuttavia il confronto tra due costanti impedisce che ciò accada nel secondo caso.

Un elenco di condizioni che impediscono la semplice parametrizzazione (precedentemente nota come auto-parametrizzazione) è disponibile nell'Appendice A del Plan Caching Microsoft Technical Papers:

• Problemi di compilazione batch, ricompilazione e pianificazione della memorizzazione nella cache in SQL Server 2005
• Pianificare la memorizzazione nella cache in SQL Server 2008
• Pianificare la memorizzazione nella cache e la ricompilazione in SQL Server 2012

la semplice parametrizzazione non è generalmente qualcosa su cui dovresti fare affidamento comunque. È molto meglio parametrizzare esplicitamente le tue query.

In qualsiasi RDBMS moderno (inclusi Oracle, Microsoft SQL Server e PostgreSQL - ne sono sicuro), ciò non avrà alcun effetto sulle prestazioni.

Come notato da qualcuno, ciò avrà effetto solo sulla fase di pianificazione delle query. Quindi la differenza sarà visibile solo quando si eseguono migliaia di iterazioni di una query semplicistica che non restituisce alcun dato, come questo:

SELECT 1 FROM empty_table; -- run this 10 000 times.

SELECT 1 FROM empty_table WHERE 1=1; -- run this 10 000 times and compare.

Per me, su PostgreSQL 9.0, questo è visibile con solo 10000 iterazioni:

filip@srv:~$ pgquerybench.pl -h /var/run/postgresql/ -q "select 1 from never where 1=1" -q "select 1 from never" -i 10000
Iterations: 10000
Query:   select 1 from never where 1=1
Total:   2.952 s
Average: 0.295 ms
Query:   select 1 from never
Total:   2.850 s
Average: 0.285 ms

Questo può essere un "problema" per Oracle quando si utilizza il parametro database cursore_sharing. Quando è impostato su "force", modificherà tutte le istruzioni SQL. Tutte le "costanti" nelle query saranno sostituite da variabili di bind (come 1 =>: SYS_0).

Questa opzione è stata introdotta per gestire alcuni sviluppatori pigri. D'altra parte può anche danneggiare altri sviluppatori pigri. Ma il rischio non è troppo elevato. Da 11g ha funzionalità di sbirciamento variabile vincolante.