SQL Server, TOP contro ROW_NUMBER


8

Sto imparando i piani di esecuzione e sto provando diverse query, confrontando le loro prestazioni e inciampando su questo:

SELECT StatisticID
FROM (
    SELECT StatisticID, ROW_NUMBER() OVER (ORDER BY StatisticID) AS rn
    FROM FTCatalog.Statistic
    ) AS T
WHERE T.rn <= 1000
ORDER BY rn

SELECT TOP 1000 StatisticID
FROM FTCatalog.Statistic
ORDER BY StatisticID

Entrambi restituiscono lo stesso set di risultati, tuttavia il primo viene eseguito più velocemente ed è meno affamato di risorse (almeno SSMS mi dice che) Ecco i piani di esecuzione: Piani di esecuzione

Confronto da SQL Query Plan Explorer: inserisci qui la descrizione dell'immagine Qualcuno potrebbe darmi un'idea di ciò che sta realmente accadendo dietro le quinte e perché i risultati differiscono? Se c'è qualcos'altro di cui hai bisogno, fammelo sapere.

Grazie Evaldas.


Per qualche motivo, SQL Server non ha una buona riscrittura delle query per le query di paging. Queste differenze nel piano e nella stima non dovrebbero esistere per un caso così comune.
usr

Risposte:


11

Immagino che stai confrontando i costi stimati per le query. Queste sono solo stime basate sul (tra l'altro) il numero stimato di righe restituite dalla query. Non il numero effettivo di righe.

La tua prima query ha stimato che avrebbe restituito 30 righe e la seconda query ha stimato 1000 righe. Ecco da dove viene la tua differenza nel costo delle query.

Se modifichi le query per recuperare solo 30 righe, vedrai che le righe stimate sono le stesse per le query e che la prima query è effettivamente un po 'più alta, almeno per me in SQL Server 2014.

Non utilizzare le stime quando si confrontano le prestazioni delle query. Usa invece cose come la durata, il numero di letture e la dimensione delle assegnazioni di memoria.


1
Per verificare le prestazioni effettive, eseguire ciascuna delle query più volte (GO 10) con l'opzione Includi statistiche client. Ho il sospetto che scoprirai che i tempi di esecuzione effettivi sono più vicini delle stime dei costi relativi. Non c'è magia sotto le coperte; gli operatori del piano di query raccontano la vera storia.
Dan Guzman,

Il costo relativo (espressione percentuale) in realtà significa qualcosa in SSMS? Questo mi infastidiva di più.
Evaldas Buinauskas,

@EvaldasBuinauskas Non sono sicuro che il costo relativo sia utile per qualsiasi cosa. Forse a volte, ma non credo che possa mai valere la confusione che crea quando le persone iniziano a utilizzare la percentuale stimata per confrontare le prestazioni di query diverse. Sarà sempre una stima e le stime sono sempre (quasi) sbagliate.
Mikael Eriksson,

@EvaldasBuinauskas, tali costi sono raccolti durante il processo di ottimizzazione ed esposti, ma non intendono essere un indicatore o i tempi di esecuzione effettivi. I costi sono solo una supposizione. Vedi blogs.msdn.com/b/sqlqueryprocessing/archive/2006/10/11/…
Dan Guzman,
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.