Query T-SQL che utilizza un piano completamente diverso a seconda del numero di righe che sto aggiornando

Ho un'istruzione SQL UPDATE con una clausola "TOP (X)" e la riga in cui sto aggiornando i valori ha circa 4 miliardi di righe. Quando utilizzo "TOP (10)", ottengo un piano di esecuzione che viene eseguito quasi istantaneamente, ma quando utilizzo "TOP (50)" o più grande, la query non (almeno, non mentre aspetto) termina e utilizza un piano di esecuzione completamente diverso. La query più piccola utilizza un piano molto semplice con una coppia di ricerche di indice e un join di ciclo nidificato, in cui la stessa query esatta (con un numero diverso di righe nella clausola TOP dell'istruzione UPDATE) utilizza un piano che prevede due ricerche di indice diverse , una bobina da tavolo, parallelismo e un sacco di altre complessità.

Ho usato "OPTION (USE PLAN ...)" per costringerlo a utilizzare il piano di esecuzione generato dalla query più piccola - quando lo faccio, posso aggiornare fino a 100.000 righe in pochi secondi. So che il piano di query è buono, ma SQL Server sceglierà quel piano da solo solo quando è coinvolto solo un piccolo numero di righe - qualsiasi conteggio delle righe abbastanza grande nel mio aggiornamento comporterà il piano non ottimale.

Ho pensato che il parallelismo potesse essere la colpa, quindi ho impostato MAXDOP 1la query, ma senza alcun risultato - quel passo è andato, ma la scelta / prestazione scadente non lo è. Ho corso anche sp_updatestatsquesta mattina per assicurarmi che non fosse la causa.

Ho allegato i due piani di esecuzione: il più breve è anche il più veloce. Inoltre, ecco la query in questione (vale la pena notare che il SELECT che ho incluso sembra essere veloce nei casi di conteggi di righe sia piccole che grandi):

    update top (10000) FactSubscriberUsage3
               set AccountID = sma.CustomerID
    --select top 50 f.AccountID, sma.CustomerID
      from FactSubscriberUsage3 f
      join dimTime t
        on f.TimeID = t.TimeID
      join #mac sma
        on f.macid = sma.macid
       and t.TimeValue between sma.StartDate and sma.enddate 
     where f.AccountID = 0 --There's a filtered index on the table for this

Ecco il piano rapido :

Ed ecco quello più lento :

C'è qualcosa di ovvio nel modo in cui sto impostando la mia query o nel piano di esecuzione purché si presti alla cattiva scelta che il motore di query sta facendo? Se necessario, posso anche includere le definizioni di tabella coinvolte e gli indici che sono definiti su di esse.

Per coloro che hanno chiesto una versione solo statistica degli oggetti del database: non avevo nemmeno capito che potevi farlo, ma ha perfettamente senso! Ho provato a generare gli script per un database di sole statistiche in modo che altri potessero testare da soli i piani di esecuzione, ma posso generare statistiche / istogrammi nel mio indice filtrato (errore di sintassi nello script, a quanto pare), quindi sono sfortunato lì. Ho provato a rimuovere il filtro e i piani di query erano vicini, ma non esattamente lo stesso, e non voglio mandare nessuno a caccia d'oca.

Aggiornamento e alcuni piani di esecuzione più completi: prima di tutto, Explorer Plan di SQL Sentry è uno strumento incredibile. Non sapevo nemmeno che esistesse fino a quando non ho visto le altre domande sul piano di query su questo sito, e aveva un bel po 'da dire su come le mie query stavano eseguendo. Sebbene non sia sicuro di come affrontare il problema, hanno reso evidente quale sia il problema.

Ecco il riepilogo per 10, 100 e 1000 righe: puoi vedere che la query di 1000 righe è molto lontana dagli altri:

Puoi vedere che la terza query ha un numero ridicolo di letture, quindi ovviamente sta facendo qualcosa di completamente diverso. Ecco il piano di esecuzione stimato, con conteggi delle righe. Piano di esecuzione stimato di 1000 righe:

Ed ecco i risultati effettivi del piano di esecuzione (a proposito, per "non finisce mai", si scopre che intendevo "finisce tra un'ora"). Piano di esecuzione effettivo di 1000 righe

La prima cosa che ho notato è che, invece di tirare 60K righe dalla tabella DimTime come si aspetta, in realtà tirando 1,6 miliardi, con un B . Guardando la mia domanda, non sono sicuro di come stia ritirando tante righe dalla tabella dimTime. L'operatore TRA che sto usando assicura solo che sto estraendo il record corretto da #mac in base al record del tempo nella tabella dei fatti. Tuttavia, quando aggiungo una riga alla clausola WHERE in cui filtro t.TimeValue (o t.TimeID) su un singolo valore, posso aggiornare con successo 100.000 righe in pochi secondi. Di conseguenza, e come chiarito nei piani di esecuzione che ho incluso, è ovvio che è il mio orario è il problema, ma non sono sicuro di come cambierei i criteri di join per aggirare questo problema e mantenere l'accuratezza . qualche idea?

Per riferimento, qui il piano (con numero di righe) per l'aggiornamento di 100 righe. Puoi vedere che colpisce lo stesso indice, e ancora con una tonnellata di righe, ma da nessuna parte vicino alla stessa entità di un problema. Esecuzione di 100 righe con numero di righe :

L'indice su dimTime sta cambiando. Il piano più veloce utilizza un indice _dta. Prima di tutto, assicurati che non sia contrassegnato come un indice ipotetico in sys.indexes.

Pensando che potresti bypassare alcune parametrizzazioni utilizzando la tabella #mac per filtrare invece di fornire solo le date di inizio / fine come questa DOVE t.TimeValue tra @StartDate e @enddate. Sbarazzati di quel tavolo temporaneo.

Senza ulteriori informazioni sui conteggi delle righe nel piano, la mia raccomandazione preliminare è di organizzare l'ordine di join corretto nella query e forzarlo utilizzando OPTION (FORCE ORDER). Applicare l'ordine di join del primo piano.