SQL si unisce a sottoquery SQL (prestazioni)?

Vorrei sapere se ho una query di join simile a questa:

Select E.Id,E.Name from Employee E join Dept D on E.DeptId=D.Id

e una sottoquery simile a questa -

Select E.Id,E.Name from Employee Where DeptId in (Select Id from Dept)

Quando considero le prestazioni quale delle due query sarebbe più veloce e perché ?

Inoltre c'è un momento in cui dovrei preferire uno sull'altro?

Scusa se questo è troppo banale e chiesto prima ma sono confuso al riguardo. Inoltre, sarebbe fantastico se voi ragazzi mi poteste suggerire gli strumenti che dovrei usare per misurare le prestazioni di due query. Molte grazie!

Mi aspetto che la prima query sia più veloce, principalmente perché hai un'equivalenza e un JOIN esplicito. Nella mia esperienza INè un operatore molto lento, poiché SQL normalmente lo valuta come una serie di WHEREclausole separate da "OR" ( WHERE x=Y OR x=Z OR...).

Come con TUTTE LE COSE SQL, tuttavia, il tuo chilometraggio può variare. La velocità dipenderà molto dagli indici (hai indici su entrambe le colonne ID? Questo ti aiuterà molto ...) tra le altre cose.

L'unico modo REALE per sapere con certezza del 100% quale è più veloce è attivare il monitoraggio delle prestazioni (le statistiche IO sono particolarmente utili) ed eseguirli entrambi. Assicurati di svuotare la cache tra una corsa e l'altra!

Beh, credo che sia una domanda "Vecchia ma d'oro". La risposta è, dipende!". Le performance sono un argomento così delicato che sarebbe troppo sciocco dire: "Non usare mai sottoquery, unisciti sempre". Nei seguenti collegamenti, troverai alcune best practice di base che ho trovato molto utili:

• Ottimizzazione delle sottoquery
• Ottimizzazione di sottoquery con trasformazioni semijoin
• Riscrittura di sottoquery come join

Ho un tavolo con 50000 elementi, il risultato che cercavo era 739 elementi.

La mia domanda all'inizio era questa:

SELECT  p.id,
    p.fixedId,
    p.azienda_id,
    p.categoria_id,
    p.linea,
    p.tipo,
    p.nome
FROM prodotto p
WHERE p.azienda_id = 2699 AND p.anno = (
    SELECT MAX(p2.anno) 
    FROM prodotto p2 
    WHERE p2.fixedId = p.fixedId 
)

e ci sono voluti 7,9 secondi per l'esecuzione.

Alla fine la mia domanda è questa:

SELECT  p.id,
    p.fixedId,
    p.azienda_id,
    p.categoria_id,
    p.linea,
    p.tipo,
    p.nome
FROM prodotto p
WHERE p.azienda_id = 2699 AND (p.fixedId, p.anno) IN
(
    SELECT p2.fixedId, MAX(p2.anno)
    FROM prodotto p2
    WHERE p.azienda_id = p2.azienda_id
    GROUP BY p2.fixedId
)

e ci sono voluti 0,0256 secondi

Buon SQL, bene.

Inizia a guardare i piani di esecuzione per vedere le differenze nel modo in cui SQl Server li interpreterà. È inoltre possibile utilizzare Profiler per eseguire effettivamente le query più volte e ottenere la differenza.

Non mi aspetto che queste siano così orribilmente diverse, dove puoi ottenere reali, grandi guadagni in termini di prestazioni utilizzando i join invece delle sottoquery è quando usi le sottoquery correlate.

EXISTS è spesso migliore di uno di questi due e quando parli di left join dove vuoi che tutti i record non siano nella tabella di left join, allora NOT EXISTS è spesso una scelta molto migliore.

Le prestazioni si basano sulla quantità di dati su cui stai eseguendo ...

Se sono meno dati intorno a 20k. JOIN funziona meglio.

Se i dati sono più simili a 100k +, IN funziona meglio.

Se non hai bisogno dei dati dell'altra tabella, IN va bene, ma è sempre meglio scegliere EXISTS.

Tutti questi criteri ho testato e le tabelle hanno indici adeguati.

La performance dovrebbe essere la stessa; è molto più importante avere gli indici e il clustering corretti applicati alle tabelle (esistono alcune buone risorse su questo argomento).

(Modificato per riflettere la domanda aggiornata)

Le due query potrebbero non essere semanticamente equivalenti. Se un dipendente lavora per più di un dipartimento (possibile nell'azienda per cui lavoro; certamente, ciò implicherebbe che la tua tabella non è completamente normalizzata), la prima query restituirebbe righe duplicate mentre la seconda query no. Per rendere le query equivalenti in questo caso, la DISTINCTparola chiave dovrebbe essere aggiunta al fileSELECT clausola, il che potrebbe avere un impatto sulle prestazioni.

Nota che esiste una regola pratica di progettazione che afferma che una tabella dovrebbe modellare un'entità / classe o una relazione tra entità / classi ma non entrambe. Pertanto, ti suggerisco di creare una terza tabella, diciamo OrgChart, per modellare la relazione tra dipendenti e dipartimenti.

So che questo è un vecchio post, ma penso che questo sia un argomento molto importante, soprattutto oggigiorno dove abbiamo 10 milioni di record e parliamo di terabyte di dati.

Approfitterò anche delle seguenti osservazioni. Ho circa 45 milioni di record nella mia tabella ([data]) e circa 300 record nella mia tabella [cats]. Ho un'ampia indicizzazione per tutte le query di cui sto per parlare.

Considera l'esempio 1:

UPDATE d set category = c.categoryname
FROM [data] d
JOIN [cats] c on c.id = d.catid

rispetto all'esempio 2:

UPDATE d set category = (SELECT TOP(1) c.categoryname FROM [cats] c where c.id = d.catid)
FROM [data] d

L'esempio 1 ha impiegato circa 23 minuti per essere eseguito. L'esempio 2 ha richiesto circa 5 minuti.

Quindi concluderei che la sottoquery in questo caso è molto più veloce. Ovviamente tieni presente che sto usando unità SSD M.2 in grado di i / o @ 1 GB / sec (cioè byte non bit), quindi anche i miei indici sono molto veloci. Quindi questo potrebbe influenzare anche le velocità nella tua circostanza

Se è una pulizia dei dati una tantum, probabilmente è meglio lasciarla in esecuzione e finire. Uso TOP (10000) e vedo quanto tempo ci vuole e moltiplico per numero di record prima di raggiungere la grande query.

Se si stanno ottimizzando i database di produzione, suggerirei caldamente di pre-elaborare i dati, ovvero utilizzare trigger o job-broker per asincronizzare i record di aggiornamento, in modo che l'accesso in tempo reale recuperi i dati statici.

Puoi utilizzare un piano di spiegazione per ottenere una risposta obiettiva.

Per il tuo problema, un filtro Exists sarebbe probabilmente il più veloce.