MySql visualizza le prestazioni

Question

Se si sta seguendo la strada dell'utilizzo delle visualizzazioni, come si può garantire una buona prestazione?

O è meglio non utilizzare le viste in primo luogo e basta incorporare l'equivalente nelle istruzioni selezionate?

Answer 1

Depende.

Dipende totalmente da ciò che si sta visualizzando attraverso la vista. Ma molto probabilmente riducendo i tuoi sforzi e dando prestazioni più elevate. Quando l'istruzione SQL fa riferimento a una vista non indicizzata, il parser e il Query Optimizer analizzano l'origine dell'istruzione SQL e della vista, quindi li risolvono in un singolo piano di esecuzione. Non esiste un piano per l'istruzione SQL e un piano separato per la vista.

Una vista non viene compilata. È un tavolo virtuale composto da altri tavoli. Quando lo crei, non risiede da qualche parte sul tuo server. Le query sottostanti che costituiscono la vista sono soggette agli stessi guadagni o alle stesse prestazioni di Query Optimizer. Non ho mai testato le prestazioni su una vista VS la sua query sottostante, ma immagino che le prestazioni potrebbero variare leggermente. È possibile ottenere prestazioni migliori su una vista indicizzata se i dati sono relativamente statici. Questo potrebbe essere ciò che stai pensando, forse in termini di "compilato".

Vantaggi di visite:

1. Visualizza i dati senza memorizzare i dati in oggetto.
2. Ristabilire la vista di una tabella, ad esempio, è possibile nascondere alcune colonne nelle tabelle.
3. Unire due o più tabelle e mostrarlo come un oggetto per l'utente.
4. Restringere l'accesso di una tabella in modo che nessuno possa inserire le righe nella tabella.

vedere questi link utili:

1. Performance of VIEW vs. SQL statement
2. Is a view faster than a simple query?
3. Mysql VIEWS vs. PHP query
4. Are MySql Views Dynamic and Efficient?
5. Materialized View vs. Tables: What are the advantages?
6. Is querying over a view slower than executing SQL directly?
7. A workaround for the performance problems of TEMPTABLE views
8. See performance gains by using indexed views in SQL Server

Answer 2

Penso che il blog di Peter Zaitsev abbia la maggior parte dei dettagli. Parlare dalle opinioni personali può funzionare bene se generalmente le mantieni semplici. A uno dei miei clienti continuavano a sovrapporre una vista sull'altra e finiva in un incubo di perfomance.

Generalmente utilizzo le viste per mostrare un aspetto diverso di una tabella. Per esempio nella tabella dei miei impiegati mostrami i gestori o nascondi il campo salariale da dipendenti non HR. Assicurati inoltre di eseguire una SPIEGA sulla query e visualizzare per capire esattamente cosa sta succedendo in MySQL.

Se si desidera una prova solida nel proprio scenario, suggerirei di eseguire il test. È davvero difficile dire che l'uso di views sia sempre un killer di prestazioni, quindi, di nuovo, una vista scritta male probabilmente ucciderà la tua performance.

Answer 3

Se stiamo discutendo di "se si utilizzano le viste, come garantire le prestazioni" e non l'effetto delle prestazioni delle visualizzazioni in generale, penso che si riduca a moderazione (come in te stesso).

È possibile ottenere grossi problemi se si scrivono solo le viste per rendere la query semplice in tutti i casi, ma non si cura che le proprie viste siano effettivamente utili per le prestazioni. Qualsiasi query che stai facendo alla fine dovrebbe essere sana di mente (vedi l'esempio di commento da quel link di @eggyal). Ovviamente è una tautologia, ma non è meno valida

In particolare, devi fare attenzione a non creare viste dalle viste, solo perché ciò potrebbe rendere più semplice la visualizzazione.

Alla fine è necessario esaminare il motivo per cui si stanno utilizzando le viste. Ogni volta che lo fai per rendere la vita più facile alla fine della programmazione potresti essere meglio con una procedura memorizzata IMHO.

Per tenere le cose sotto controllo, potresti voler annotare il motivo per cui hai una determinata vista e decidere perché la stai usando. Per ogni 'nuovo' utilizzo all'interno della tua programmazione, ricontrolla se hai effettivamente bisogno della vista, perché ne hai bisogno, e se questo ti darebbe comunque un percorso di esecuzione sano. Continua a controllare i tuoi usi per mantenerlo veloce e continua a controllare se hai davvero bisogno di quella vista.

Answer 4

Ecco un riepilogo di tl; dr, puoi trovare valutazioni dettagliate da Peter Zaitsev e altrove.

Le viste in MySQL sono in genere una cattiva idea. A Grooveshark li consideriamo dannosi e li evitiamo sempre. Se fai attenzione, puoi farli funzionare, ma nel migliore dei casi sono un modo per ricordare come selezionare i dati o impedirti di ridigitare i join complicati. Nel peggiore dei casi possono causare enormi inefficienze, nascondere la complessità, causare subselect annidati accidentali (che richiedono tabelle temporanee e portare al disco thrashing), ecc.

È meglio evitarli e mantenere le query nel codice.

Answer 5

Servono al loro scopo, ma le complessità e le inefficienze nascoste di solito superano un approccio più diretto. Una volta ho incontrato un'istruzione SQL che si stava unendo su due viste e ordinandole i risultati. Anche le visualizzazioni erano ordinate, quindi il tempo di esecuzione poteva essere misurato in quelle che sembravano ore.

Answer 6

Una cosa non menzionata finora, ma fare una grande differenza è adeguata indicizzazione dei punti di vista fonte tabelle.

Come accennato in precedenza, parere non risiedono nel vostro DB ma sono ricostruire ogni volta. Quindi tutto ciò che rende la ricostruzione più semplice per il DB aumenta le prestazioni della vista.

Spesso le viste si uniscono ai dati in un modo molto negativo per l'archiviazione (nessuna forma normale) ma molto utile per un ulteriore utilizzo (analisi, presentazione dei dati all'utente, ...) e di conseguenza unione e aggregazione di dati da diversi tabelle.

Indipendentemente dal fatto che le colonne su cui vengono eseguite le operazioni siano indicizzate o meno, fa una grande differenza sulle prestazioni di una vista. Se le tabelle e le relative colonne pertinenti sono indicizzate, l'accesso alla vista non termina con il ricalcolo degli indici più e più volte prima.(sul lato inferiore, questo viene fatto quando i dati vengono manipolati nelle tabelle di origine)

! Indicizza tutte le colonne utilizzate nelle clausole JOINS e GROUP BY nell'istruzione CREATE VIEW!