Una query WHERE eseguirà controlli su confronti più semplici (ad es. Bit) prima di eseguire confronti più ardui (ad es. Varchar)?


12

Se scrivo una query che include una WHEREclausola composta , ad esempio:

SELECT *
FROM MyTable
WHERE BitField = 1
    AND VarcharField = 'asdf'

e l'inclusione di quel bitconfronto esclude semplicemente gli stessi campi che il varcharconfronto escluderà, la presenza di quel bitconfronto di campo mi renderà un miglioramento delle prestazioni?

Risposte:


22

È importante riconoscere che SQL è un linguaggio dichiarativo. La SELECTquery che hai scritto specifica i risultati logici che dovrebbero essere restituiti. Spetta al motore di database, in particolare Query Optimizer, determinare una strategia fisica efficiente per restituire tali risultati.

Il piano di esecuzione fisica finale dipenderà dalle capacità di ragionamento dell'ottimizzatore, dalla quantità di tempo che è disposto a spendere per il problema, dalla disponibilità di metodi di accesso adeguati (principalmente indici e viste materializzate), informazioni statistiche rappresentative e il particolare percorso del codice la specifica della query richiede il codice di ottimizzazione.

In generale, se la progettazione del tuo database è relazionale, fornisci buoni metodi di accesso e informazioni statistiche accurate e la query è ben scritta, l'ottimizzatore normalmente troverà una ragionevole strategia di esecuzione fisica senza che tu debba preoccuparti troppo della forma scritta di le specifiche della query troppo.

Ci saranno sempre casi in cui esprimere lo stesso requisito logico usando una sintassi diversa (ma semanticamente identica) influenzerà il piano di esecuzione fisica, ma questo dovrebbe essere un problema secondario. Anche in questo caso, in genere, considerare di esprimere la query in modo diverso solo se le caratteristiche di runtime sono inaccettabili, una volta che tutte le basi di cui sopra sono state coperte.

Sarebbe raro all'estremo che l'ordine scritto dei semplici WHEREpredicati della clausola congiuntiva (come nella domanda) influenzi il piano di esecuzione fisica in qualsiasi modo misurabile. In breve, questo non è qualcosa di cui dovresti perdere tempo a preoccuparti. Ottieni subito la progettazione del database, gli indici e le informazioni statistiche.

Per rispondere direttamente alla domanda (eventualmente!), L'aggiunta della condizione ridondante aggiuntiva potrebbe migliorare le prestazioni, ma solo se consente l'uso di un metodo di accesso più efficiente, ad esempio se è presente solo un indice (BitField, VarcharField). Se fosse già presente un indice su (VarcharField), aggiungerebbe solo il sovraccarico.

Come dettaglio dell'implementazione, no, SQL Server non considera il costo dei confronti in base al tipo di dati o all'apparente complessità computazionale. In effetti, vi è un piccolo costo prezioso per le operazioni scalari , ma ciò porta a un argomento completamente separato.

Domande correlate:

Operatori logici OR AND in condizioni e ordine delle condizioni in WHERE
SQL Server 2008 ed espressioni costanti
Operatori bit a bit che influiscono sulle prestazioni Strano comportamento dell'istruzione
SQL


5

Le partizioni binarie (come una colonna di bit) sembrano buoni candidati per gli indici filtrati.

CREATE NONCLUSTERED INDEX MyTableWithBitFieldTrue
ON MyTable (VarcharField)
INCLUDE Id, <other columns you're selecting>
WHERE BitField = 1 ;
GO

Essere espliciti sulle tue ottimizzazioni significa che il tuo codice è più robusto rispetto alle modifiche di altre persone, sia nella tua base di codice che in SQL Server.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.