Esistono alcuni modi per garantire la ricompilazione di una stored procedure:
- usando
WITH RECOMPILE, - rendere dinamica la procedura memorizzata (pensa a
exec()) - contrassegnare il proc per la ricompilazione con
sp_recompile. - modifica dello schema su cui si basa un piano di query memorizzato nella cache
- chiamando
DBCC FREEPROCCACHE - A livello di query, una singola istruzione all'interno di un proc può essere ricompilata con l'hint di query RECOMPILE (SQL 2008).
Fattori nella ricompilazione
Oltre ai fattori difficili sopra elencati, quali sono le cause della ricompilazione della stored procedure? Beh, un sacco di cose. Alcuni di questi sono intrecciati con l'elenco sopra, ma voglio presentarli di nuovo b/c potrebbe non essere ovvio.
- Inserimento o eliminazione di molti dati (la densità dei dati negli indici e nelle tabelle spesso controlla i piani di query)
- Ricostruire gli indici (una modifica agli oggetti sottostanti)
- Creazione/eliminazione di tabelle temporanee (di nuovo, modifiche DML sottostanti).
- il piano di query scade (pensare non utilizzato di recente e sql vuole ripulire l'uso della memoria)
Questo non è affatto un elenco esaustivo. Query Optimizer si evolve e sorprende indipendentemente da quanto tempo utilizzi SQL Server. Ma ecco alcune risorse che potrebbero essere utili:
- Risoluzione dei problemi di ricompilazione delle stored procedure (un vecchio, ma un buono)
- Ricompilazione delle stored procedure
- Ottimizzazione delle stored procedure di SQL Server per evitare le ricompilazioni
- Memorizzazione e riutilizzo del piano di esecuzione (da leggere)
MA ASPETTA - C'È DI PIÙ!
Detto questo, la presunzione nella tua domanda è che le ricompilazioni siano sempre dannose per le prestazioni. In effetti, spesso la riconciliazione è buona.
Quindi, quando vorresti che si ricompilasse? Diamo un'occhiata a un esempio di un processo che ricerca per cognome. Le stored procedure eseguono 'sniffing dei parametri
' che è una benedizione (se funziona per te) e una maledizione (se funziona contro di te). Primo passaggio qualcuno cerca su Zebr% per zerbrowski. L'indice del cognome si rende conto che questo è molto specifico e restituirà, diciamo, 3 righe da un milione, quindi viene creato un piano di esecuzione. Con il proc compilato per un risultato di riga bassa, la ricerca successiva è per S% . Bene, S è il tuo nome più comune e corrisponde a 93.543 righe su 1 milione.
