Una visualizzazione è più veloce di una semplice query?

È un

select * from myView 

più veloce della query stessa per creare la vista (per avere lo stesso resultSet):

 select * from ([query to create same resultSet as myView]) 

?

Non mi è del tutto chiaro se la vista utilizza una sorta di memorizzazione nella cache rendendola più veloce rispetto a una semplice query.

, le viste possono avere un indice cluster assegnato e, quando lo fanno, memorizzeranno risultati temporanei che possono accelerare le query risultanti.

Aggiornamento: almeno tre persone mi hanno votato su questo. Con tutto il dovuto rispetto, penso che siano semplicemente sbagliati; La documentazione di Microsoft rende molto chiaro che Views può migliorare le prestazioni.

In primo luogo, le viste semplici vengono espanse e quindi non contribuiscono direttamente al miglioramento delle prestazioni, tanto è vero. Tuttavia, le visualizzazioni indicizzate possono migliorare notevolmente le prestazioni.

Lasciami andare direttamente alla documentazione:

Dopo aver creato un indice cluster univoco sulla vista, la serie di risultati della vista viene materializzata immediatamente e mantenuta nella memoria fisica nel database, risparmiando il sovraccarico di eseguire questa operazione costosa al momento dell’esecuzione.

In secondo luogo, queste viste indicizzate possono funzionare anche quando non vengono referenziate direttamente da un’altra query, in quanto l’ottimizzatore le utilizzerà al posto di un riferimento alla tabella, quando appropriato.

Di nuovo, la documentazione:

La vista indicizzata può essere utilizzata in un’esecuzione di query in due modi. La query può fare riferimento direttamente alla vista indicizzata o, cosa più importante, Query Optimizer può selezionare la vista se determina che la vista può essere sostituita per alcune o tutte le query nel piano di query a basso costo. Nel secondo caso, viene utilizzata la vista indicizzata al posto delle tabelle sottostanti e dei loro indici ordinari. Non è necessario fare riferimento alla vista nella query affinché Query Optimizer lo utilizzi durante l’esecuzione della query. Ciò consente alle applicazioni esistenti di beneficiare delle viste indicizzate appena create senza modificare tali applicazioni.

Questa documentazione, così come i grafici che dimostrano i miglioramenti delle prestazioni, possono essere trovati qui .

Aggiornamento 2: la risposta è stata criticata sulla base del fatto che è “l’indice” che fornisce il vantaggio prestazionale, non la “Vista”. Tuttavia, questo è facilmente confutabile.

Diciamo che siamo un’azienda di software in un piccolo paese; Userò la Lituania come esempio. Vendiamo software in tutto il mondo e conserviamo i nostri record in un database SQL Server. Abbiamo molto successo e così, in pochi anni, abbiamo oltre 1.000.000 di dischi. Tuttavia, spesso abbiamo bisogno di segnalare le vendite a fini fiscali e scopriamo che abbiamo venduto solo 100 copie del nostro software nel nostro paese. Creando una vista indicizzata dei soli record lituani, otteniamo i record di cui abbiamo bisogno in una cache indicizzata come descritto nella documentazione MS. Quando pubblichiamo i nostri rapporti per le vendite lituane nel 2008, la nostra ricerca cercherà un indice con una profondità di appena 7 (Log2 (100) con alcune foglie inutilizzate). Se dovessimo fare lo stesso senza VISTA e fare semplicemente affidamento su un indice nella tabella, dovremmo attraversare un albero degli indici con una profondità di ricerca di 21!

Chiaramente, la Vista stessa ci fornirebbe un vantaggio in termini di prestazioni (3x) rispetto al semplice utilizzo dell’indice da solo. Ho provato a utilizzare un esempio reale, ma noterai che un semplice elenco di vendite lituane ci darebbe un vantaggio ancora maggiore.

Nota che sto solo usando un b-tree dritto per il mio esempio. Mentre sono abbastanza certo che SQL Server utilizza alcune varianti di un b-tree, non conosco i dettagli. Tuttavia, il punto vale.

Aggiornamento 3: è sorta la domanda se una Vista indicizzata utilizza solo un indice posizionato sulla tabella sottostante. Cioè, per parafrasare: “una vista indicizzata è solo l’equivalente di un indice standard e non offre nulla di nuovo o unico per una vista”. Se fosse vero, ovviamente, l’analisi di cui sopra sarebbe errata! Consentitemi di fornire una citazione dalla documentazione Microsoft che dimostri perché ritengo che questa critica non sia valida o vera:

Utilizzare gli indici per migliorare le prestazioni della query non è un nuovo concetto; tuttavia, le viste indicizzate offrono ulteriori vantaggi in termini di prestazioni che non possono essere ottenuti utilizzando indici standard.

Insieme alla citazione sopra riguardante la persistenza dei dati nella memoria fisica e altre informazioni nella documentazione su come gli indici sono creati su Views, penso che sia sicuro dire che una Vista indicizzata non è solo un SQL memorizzato nella cache Selezionare quello che accade per usare un indice definito sulla tabella principale. Quindi, continuo a sopportare questa risposta.

In generale, no. Le viste vengono principalmente utilizzate per comodità e sicurezza, non per miglioramenti della velocità.

Detto questo, SQL Server 2000 e versioni successive dispongono di una funzione speciale denominata Visualizzazioni indicizzate che può migliorare notevolmente le prestazioni, ma è necessario creare visualizzazioni indicizzate seguendo un insieme molto specifico di linee guida .

C’è un riferimento importante nella documentazione online per quanto riguarda la risoluzione delle immagini .

Ecco un articolo che descrive i vantaggi e la creazione di viste indicizzate :

Per molti anni, Microsoft® SQL Server ™ ha supportato la possibilità di creare tabelle virtuali note come viste. Storicamente, queste visualizzazioni servivano a questi scopi principali:

  • Fornire un meccanismo di sicurezza che limiti gli utenti a un determinato sottoinsieme di dati in una o più tabelle di base.

  • Fornire un meccanismo che consenta agli sviluppatori di personalizzare il modo in cui gli utenti possono visualizzare logicamente i dati memorizzati nelle tabelle di base.

Con SQL Server 2000, la funzionalità delle viste di SQL Server è stata ampliata per fornire vantaggi in termini di prestazioni del sistema. È ansible creare un indice cluster univoco su una vista, nonché indici non cluster, per migliorare le prestazioni di accesso ai dati nelle query più complesse. In SQL Server 2000 e 2005, una vista con un indice cluster univoco viene definita una vista indicizzata.

Almeno in SQL Server, i piani di query vengono archiviati nella cache del piano per entrambe le viste e per le query SQL ordinarie, in base ai parametri di query / visualizzazione. Per entrambi, vengono rilasciati dalla cache quando non sono stati utilizzati per un periodo sufficientemente lungo e lo spazio è necessario per un’altra query appena inviata. Dopodiché, se viene emessa la stessa query, questa viene ricompilata e il piano viene reinserito nella cache. Quindi no, non c’è differenza, dato che stai riutilizzando la stessa query SQL e la stessa vista con la stessa frequenza.

Ovviamente, in generale, una visione, per sua stessa natura (che qualcuno pensava che dovesse essere usata abbastanza spesso per trasformarla in una vista) è generalmente più probabile che sia “riutilizzata” rispetto a qualsiasi istruzione SQL arbitraria.

EDIT: ho sbagliato, e dovresti vedere la risposta di Mark sopra.

Non posso parlare per esperienza con SQL Server , ma per la maggior parte dei database la risposta sarebbe no. L’unico vantaggio potenziale che si ottiene, in termini di prestazioni, dall’utilizzo di una vista è che potrebbe potenzialmente creare alcuni percorsi di accesso in base alla query. Ma la ragione principale per usare una vista è semplificare una query o standardizzare un modo di accedere ad alcuni dati in una tabella. In generale, non otterrai un vantaggio in termini di prestazioni. Potrei sbagliarmi, però.

Troverò un esempio moderatamente più complicato e tempo da vedere da solo.

Potrebbe essere più veloce se si crea una vista materializzata ( con associazione dello schema ). Le viste non materializzate vengono eseguite esattamente come la query normale.

La mia comprensione è che un po ‘di tempo fa, una vista sarebbe più veloce perché SQL Server poteva memorizzare un piano di esecuzione e quindi usarlo invece di provare a crearne uno al volo. Penso che i guadagni in termini di prestazioni al giorno d’oggi probabilmente non siano grandi come una volta, ma dovrei immaginare che ci sarebbe un miglioramento marginale per usare la vista.

Mi aspetto che le due query si comportino in modo identico. Una vista non è altro che una definizione di query memorizzata, non c’è memorizzazione nella cache o memorizzazione di dati per una vista. L’ottimizzatore trasformsrà efficacemente la prima query nella seconda query al momento dell’esecuzione.

Sicuramente una vista è migliore di una query nidificata per SQL Server. Senza sapere esattamente perché è meglio (fino a quando ho letto il post di Mark Brittingham), avevo eseguito alcuni test e sperimentato miglioramenti delle prestazioni quasi scioccanti quando si utilizzava una vista rispetto a una query nidificata. Dopo aver eseguito ogni versione della query diverse centinaia di volte di seguito, la versione della query della vista è stata completata in metà tempo. Direi che è una prova sufficiente per me.

Non c’è alcuna pratica diversa e se leggi BOL scoprirai che mai il tuo semplice vecchio SQL SELECT * FROM X sfrutta il caching del piano, ecc.

Ci dovrebbe essere qualche guadagno insignificante nell’avere il piano di esecuzione memorizzato, ma sarà trascurabile.

Lo scopo di una vista è di utilizzare la query più e più volte. A tal fine, SQL Server, Oracle, ecc. Forniranno in genere una versione “cache” o “compilata” della visualizzazione, migliorando così le sue prestazioni. In generale, questo dovrebbe funzionare meglio di una “semplice” query, anche se se la query è veramente molto semplice, i benefici potrebbero essere trascurabili.

Ora, se stai facendo una query complessa, crea la vista.

Nella mia ricerca, l’utilizzo della vista è un po ‘più veloce di una query normale. La procedura memorizzata richiedeva circa 25 minuti (lavorando con un set di record più grande e più join diversi) e dopo aver usato la vista (non in cluster), le prestazioni erano leggermente più veloci ma non significative. Ho dovuto usare qualche altro metodo / metodo di ottimizzazione delle query per renderlo un cambiamento radicale.

Tutto dipende dalla situazione. Le viste indicizzate MS SQL sono più veloci di una normale visualizzazione o query, ma le viste indicizzate non possono essere utilizzate in un database con mirroring (MS SQL).

Una vista in qualsiasi tipo di loop causerà un grave rallentamento perché la vista viene ripopolata ogni volta che viene richiamata nel ciclo. Come una query. In questa situazione, una tabella temporanea che utilizza # o @ per mantenere i dati in loop è più veloce di una vista o una query.

Quindi tutto dipende dalla situazione.

Selezionare da una vista o da una tabella non ha molto senso.

Naturalmente se la vista non ha join, campi, ecc. Non necessari. È ansible controllare il piano di esecuzione delle query, dei join e degli indici utilizzati per migliorare il rendimento della vista.

È anche ansible creare indici sulle viste per requisiti di ricerca più rapidi. http://technet.microsoft.com/en-us/library/cc917715.aspx

Ma se stai cercando come ‘% …%’ rispetto al motore sql non trarrà vantaggio da un indice sulla colonna di testo. Se riesci a costringere i tuoi utenti a fare ricerche come “…%”, allora sarà veloce

cui si fa riferimento ai forum asp: https://forums.asp.net/t/1697933.aspx?Which+is+faster+when+using+SELECT+query+VIEW+o+Table+