Quando si cerca di capire come viene eseguita un'istruzione SQL, a volte si consiglia di esaminare il piano di spiegazione. Qual è il processo da seguire per interpretare (dare un senso) a un piano di spiegazione? Cosa dovrebbe risaltare come "Oh, funziona magnificamente?" contro "Oh no, non è giusto".
Risposte:
Rabbrividisco ogni volta che vedo commenti che le tabelle complete sono cattive e l'accesso all'indice è buono. Scansioni complete di tabelle, scansioni di intervalli di indici, scansioni di indici complete e veloci, cicli annidati, merge join, hash join ecc. Sono semplicemente meccanismi di accesso che devono essere compresi dall'analista e combinati con una conoscenza della struttura del database e lo scopo di una query in per giungere a qualsiasi conclusione significativa.
Una scansione completa è semplicemente il modo più efficiente di leggere una gran parte dei blocchi di un segmento di dati (una tabella o una partizione di tabella (sotto)) e, sebbene spesso possa indicare un problema di prestazioni, questo è solo nel contesto se è un meccanismo efficiente per raggiungere gli obiettivi della query. Parlando come un data warehouse e un ragazzo di BI, il mio flag di avvertimento numero uno per le prestazioni è un metodo di accesso basato su indice e un ciclo annidato.
Quindi, per il meccanismo di come leggere un piano di spiegazione, la documentazione di Oracle è una buona guida: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009
Buona lettura anche della Guida all'ottimizzazione delle prestazioni.
Avere anche un google per "feedback di cardinalità", una tecnica in cui un piano di spiegazione può essere utilizzato per confrontare le stime di cardinalità in varie fasi di una query con le cardinalità effettive sperimentate durante l'esecuzione. Wolfgang Breitling è l'autore del metodo, credo.
Quindi, in conclusione: capire i meccanismi di accesso. Comprendi il database. Comprendi l'intenzione della query. Evita le regole pratiche.
Questo argomento è troppo grande per rispondere a una domanda come questa. Dovresti dedicare del tempo alla lettura della Guida all'ottimizzazione delle prestazioni di Oracle
I due esempi seguenti mostrano una scansione COMPLETA e una scansione VELOCE utilizzando un INDICE.
È meglio concentrarsi sul costo e sulla cardinalità. Guardando gli esempi, l'utilizzo dell'indice riduce il costo di esecuzione della query.
È un po 'più complicato (e non ho un handle al 100%) ma fondamentalmente il costo è una funzione del costo della CPU e dell'IO e la cardinalità è il numero di righe che Oracle si aspetta di analizzare. Ridurli entrambi è una buona cosa.
Non dimenticare che il costo di una query può essere influenzato dalla tua query e dal modello di ottimizzazione Oracle (es: COST, CHOOSE ecc.) E dalla frequenza con cui esegui le statistiche.
Esempio 1:
SCANSIONE http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b
Esempio 2 utilizzando gli indici:
INDICE http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b
E come già suggerito, fai attenzione a TABLE SCAN. In genere puoi evitarli.
Cercare cose come le scansioni sequenziali può essere in qualche modo utile, ma la realtà è nei numeri ... tranne quando i numeri sono solo stime! Ciò che di solito è molto più utile che guardare un piano di query è osservare l'effettiva esecuzione . In Postgres, questa è la differenza tra EXPLAIN e EXPLAIN ANALYZE. EXPLAIN ANALYZE esegue effettivamente la query e ottiene informazioni sui tempi reali per ogni nodo. Ciò ti consente di vedere cosa sta realmente accadendo, invece di ciò che il pianificatore pensa che accadrà. Molte volte scoprirai che una scansione sequenziale non è affatto un problema, ma è qualcos'altro nella query.
L'altra chiave è identificare qual è l'effettivo passaggio costoso. Molti strumenti grafici useranno frecce di dimensioni diverse per indicare quanto costano le diverse parti del piano. In tal caso, cerca i passaggi con frecce sottili in arrivo e una freccia spessa in uscita. Se non stai utilizzando una GUI, dovrai osservare i numeri e cercare dove improvvisamente diventano molto più grandi. Con un po 'di pratica diventa abbastanza facile individuare le aree problematiche.
Davvero per problemi come questi, la cosa migliore da fare è ASKTOM . In particolare, la sua risposta a questa domanda contiene collegamenti al documento Oracle in linea, dove vengono spiegati molti di questi tipi di regole.
Una cosa da tenere a mente è che spiegare i piani sono davvero le ipotesi migliori.
Sarebbe una buona idea imparare a usare sqlplus e sperimentare con il comando AUTOTRACE. Con alcuni numeri difficili, in genere puoi prendere decisioni migliori.
Ma dovresti ASKTOM. Lo sa tutto :)
L'output della spiegazione ti dice quanto tempo ha impiegato ogni passaggio. La prima cosa è trovare i passaggi che hanno richiesto molto tempo e capire cosa significano. Cose come una scansione sequenziale ti dicono che hai bisogno di indici migliori - è principalmente una questione di ricerca nel tuo database e nella tua esperienza.
Un "Oh no, non è giusto" è spesso sotto forma di una scansione della tabella . Le scansioni delle tabelle non utilizzano indici speciali e possono contribuire all'eliminazione di ogni utile nelle cache di memoria. In postgreSQL, ad esempio, troverai che assomiglia a questo.
Seq Scan on my_table (cost=0.00..15558.92 rows=620092 width=78)
A volte le scansioni di tabelle sono ideali, ad esempio, utilizzando un indice per interrogare le righe. Tuttavia, questo è uno di quei modelli di bandiera rossa che sembri cercare.
Fondamentalmente, dai un'occhiata a ciascuna operazione e vedi se le operazioni "hanno senso" data la tua conoscenza di come dovrebbe essere in grado di funzionare.
Ad esempio, se stai unendo due tabelle, A e B nelle rispettive colonne C e D (AC = BD), e il tuo piano mostra una scansione dell'indice cluster (termine SQL Server - non sono sicuro del termine Oracle) sulla tabella A, quindi un ciclo nidificato si unisce a una serie di ricerche di indici cluster sulla tabella B, potresti pensare che ci fosse un problema. In questo scenario, potresti aspettarti che il motore esegua una coppia di scansioni degli indici (sugli indici nelle colonne unite) seguite da un'unione di unione. Ulteriori indagini potrebbero rivelare statistiche errate che inducono l'ottimizzatore a scegliere quel modello di join o un indice che in realtà non esiste.
guarda la percentuale di tempo trascorso in ogni sottosezione del piano e considera cosa sta facendo il motore. ad esempio, se sta scansionando una tabella, prendi in considerazione l'inserimento di un indice nel campo (i) che sta scansionando
Cerco principalmente scansioni di indici o tabelle. Questo di solito mi dice che mi manca un indice su una colonna importante che si trova nell'istruzione where o nell'istruzione join.
Da http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx :
Se si vede uno qualsiasi dei seguenti elementi in un piano di esecuzione, è necessario considerarli segnali di avvertimento e indagare su potenziali problemi di prestazioni. Ognuno di loro è tutt'altro che ideale dal punto di vista delle prestazioni.
* Index or table scans: May indicate a need for better or additional indexes. * Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement. * Filter: Remove any functions in the WHERE clause, don't include wiews in your Transact-SQL code, may need additional indexes. * Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently?Non è sempre possibile evitarli, ma più è possibile evitarli, più veloci saranno le prestazioni delle query.
(probabilmente vorrai leggere anche i dettagli:
Scansioni di tabelle di diverse tabelle di grandi dimensioni
Utilizzo di un indice univoco L'indice
include tutti i campi obbligatori
In circa il 90% dei problemi di prestazioni che ho riscontrato, la vittoria più semplice è suddividere una query con un sacco (4 o più) di tabelle in 2 query più piccole e una tabella temporanea.