Quando si eseguono le seguenti query in MS SQL Server 2012, la seconda query ha esito negativo ma non la prima. Inoltre, se eseguito senza le clausole where, entrambe le query falliranno. Sono in perdita perché uno dei due fallirebbe poiché entrambi dovrebbero avere set di risultati vuoti. Qualsiasi aiuto / approfondimento è apprezzato.
create table #temp
(id int primary key)
create table #temp2
(id int)
select 1/0
from #temp
where id = 1
select 1/0
from #temp2
where id = 1Risposte:
Un primo sguardo ai piani di esecuzione mostra che l'espressione 1/0è definita negli operatori di calcolo scalare:
Ora, anche se i piani di esecuzione iniziano a essere eseguiti all'estrema sinistra, chiamando ripetutamente Opene GetRowmetodi su iteratori secondari per restituire risultati, SQL Server 2005 e versioni successive contengono un'ottimizzazione per cui le espressioni sono spesso definite solo da uno scalare di calcolo, con valutazione differita fino a una successiva l'operazione richiede il risultato :
In questo caso, il risultato dell'espressione è necessario solo quando si assembla la riga per il ritorno al client (cosa che si può pensare di accadere SELECTsull'icona verde ). Secondo tale logica, una valutazione differita significherebbe che l'espressione non viene mai valutata perché nessuno dei due piani genera una riga di ritorno. Per elaborare un po 'il punto, né la Ricerca indice cluster né la Scansione tabella restituiscono una riga, quindi non vi è alcuna riga da assemblare per il ritorno al client.
Tuttavia, esiste un'ottimizzazione separata per cui alcune espressioni possono essere identificate come costanti di runtime e quindi valutate una volta prima dell'inizio dell'esecuzione della query . In questo caso, un'indicazione che si è verificata può essere trovata nello showplan XML (piano di ricerca dell'indice cluster a sinistra, piano di scansione della tabella a destra):
Ho scritto di più sui meccanismi sottostanti e su come possono influenzare le prestazioni in questo post del blog . Utilizzando le informazioni fornite lì, possiamo modificare la prima query in modo che entrambe le espressioni vengano valutate e memorizzate nella cache prima dell'inizio dell'esecuzione:
select 1/0 * CONVERT(integer, @@DBTS)
from #temp
where id = 1
select 1/0
from #temp2
where id = 1Ora, il primo piano contiene anche un riferimento di espressione costante ed entrambe le query producono il messaggio di errore. L'XML per la prima query contiene:
Ulteriori informazioni: calcolare scalari, espressioni e prestazioni
Ho intenzione di indovinare in modo intelligente (e nel processo probabilmente attirare un guru di SQL Server che potrebbe dare una risposta davvero dettagliata).
La prima query si avvicina all'esecuzione come:
Sceglie questo percorso perché hai una whereclausola sulla chiave primaria. Non arriva mai al secondo passaggio, quindi la query non fallisce.
Il secondo non ha una chiave primaria su cui eseguire, quindi si avvicina alla query come:
Uno di questi valori sta 1/0causando il problema.
Questo è un esempio di SQL Server che ottimizza la query. Per la maggior parte, questa è una buona cosa. SQL Server sposta le condizioni dall'operazione di selectscansione nella tabella. Questo spesso consente di risparmiare passaggi nella valutazione della query.
Ma questa ottimizzazione non è una cosa positiva. In effetti, sembra violare la stessa documentazione di SQL Server che afferma che la whereclausola viene valutata prima di select. Bene, potrebbero avere qualche spiegazione erudita sul significato di questo. Per la maggior parte degli umani, tuttavia, elaborare logicamente il whereprecedente selectsignificherebbe (tra le altre cose) "non generare selecterrori -clause su righe non restituite all'utente".