Visualizzazione di SQL Server 2005 vs Visualizzazione materializzata vs Stored procedure

Question

Se ho una tabella che contiene decine di migliaia di record di account per più posizioni.

C'è qualche differenza di velocità se eseguo una query su una vista che seleziona tutti gli account per una posizione specifica e una procedura memorizzata con la stessa istruzione SQL?

EDIT: mi sono imbattuto in questa vista materializzata. Sembra che questo sarebbe sempre usato.

Quando vorresti utilizzare una procedura del negozio, una vista e una vista materializzata? Quali pro e contro vuoi tenere a mente quando prendi questa decisione?

Answer 1

Risposta breve: " dipende "

Risposta più lunga: " dipende dalla forma della query "

Come per qualsiasi domanda relativa alle prestazioni in SQL Server (per di più: x vs y), non esiste una risposta corretta. Nel caso di view vs. sprocs, non c'è modo di prevedere in modo affidabile quale (se presente) sarà più veloce, a meno di profilare la query.

Ho visto entrambi essere più veloci, e dipende da come è stata utilizzata la vista e se fa parte di una query più grande. Ho anche visto le query rallentare le query perché possono nascondere molta complessità che la query che utilizza la vista in realtà non ha bisogno.

Devi valutare ciò che stai cercando di ottenere: se tutto ciò che stai facendo è voler accedere alle righe della tabella e non vuoi utilizzare l'output come parte di un'altra query, scegliere una procedura memorizzata, soprattutto se la query sulla tabella prenderà alcune clausole WHERE.

Da dove verrà chiamata la query? Un'altra parte di SQL? Qualche framework applicativo? Un livello di accesso ai dati personalizzato? Vale la pena pensare a come il codice chiamante metterà insieme la query, poiché ciò può influire sul modo in cui SQL Server finisce per memorizzare nella cache e riutilizzare il piano di esecuzione. Se collega semplicemente un insieme di SQL dinamico, le prestazioni potrebbero risentirne leggermente poiché SQL Server potrebbe dover ricostruire il piano di query ogni volta; quindi in questo caso uno sproc ha il vantaggio con un piano memorizzato nella cache. Se il livello di accesso è intelligente e ha parametrizzato SQL dinamico, potrebbe non esserci molto in esso.

Conclusione: capire cosa vuoi ottenere. Quindi profilare, sintonizzare, modificare e ripetere fino a quando non è soddisfatto.

Answer 2

Una vista e una procedura memorizzata sono entrambe compilate nel database in modo che siano più veloci di una query diretta, la differenza di velocità tra loro appare quando è necessario disporre di parametri dinamici. Le opinioni semplicemente non le accettano.

Ognuno ha il suo uso specifico. Le viste possono essere utilizzate in altre query o viste, le procedure memorizzate possono essere eseguite solo. Ma alla tua domanda con lo stesso SELEZIONA * DA hanno esattamente la stessa velocità.

Answer 3

Sì e no.

Una vista è una definizione di query che viene sostanzialmente sostituita sul posto quando utilizzata e viene compilata nella query che fa riferimento alla vista. Ciò significa che l'esecuzione effettiva dipende dalla query che fa riferimento alla vista . Se la query è un SELECT * FROM view semplice, allora questo sarà praticamente lo stesso piano di esecuzione della procedura equivalente. Tuttavia, se la query è SELEZIONA una vista DA campo , la query è significativamente diversa. Non esiste una procedura equivalente e questa query potrebbe funzionare in modo significativamente migliore a causa dell'elenco di proiezioni ridotto

Ci sono anche enormi differenze di usabilità. Una procedura memorizzata può essere eseguita solo. Una vista può essere selezionata da e utilizzata con più altre istruzioni come join, sottoquery e simili.

Data la flessibilità molto migliore delle viste, a meno che nessun altro fattore abbia un ruolo, una procedura ha senso solo se si hanno parametri, poiché le viste non possono avere parametri.

Answer 4

Le risposte a questo Pubblica fornirà un utile sfondo delle viste indicizzate (materializzate) in SQL Server.

Answer 5

Ho anche visto l'uno più veloce dell'altro, a seconda del contesto.

La regola generale che seguo è: se la vista ha un DOVE complesso, dipende da altre viste moderatamente complesse o è il risultato di UNION [ALL], allora quasi sicuramente SQL S. non sarà in grado di propagare le condizioni DOVE applicate alla vista fino alle singole tabelle, quindi a un certo punto inizierai a ottenere Scansioni delle tabelle (a meno che non sia una vista materializzata) oi tuoi piani di esecuzione saranno molto più complessi (e lenti) di ciò che essi potrebbe essere.

In questi casi, meglio andare per un proc. E come altri hanno già detto, profila sempre!