Come si fa a interpretare una query spiegare il piano?

StackOverflow https://stackoverflow.com/questions/79266

Domanda

Quando si tenta di capire come una istruzione SQL è in esecuzione, a volte è consigliabile guardare il piano di spiegare.Che cosa è il processo che si deve andare attraverso l'interpretazione (il senso) di un piano di spiegare?Ciò che dovrebbe stare fuori, come, "Oh, questo è un lavoro splendidamente?" versus "Oh no, che non è giusto."

È stato utile?

Soluzione

Mi vengono i brividi ogni volta che vedo i commenti che completa tablescans sono cattivi e indice di accesso è buono.Completa l'analisi della tabella, indice di gamma scansioni, completa e veloce analisi di indici, di cicli nidificati, merge join hash join ecc.sono semplicemente i meccanismi di accesso, che deve essere intesa dall'analista e combinato con una conoscenza della struttura del database e lo scopo di una query per raggiungere qualsiasi significativa conclusione.

Una scansione completa è semplicemente il modo più efficiente per la lettura di una grande percentuale di blocchi di un segmento di dati (una tabella o di una tabella (sotto)partizione), e, mentre spesso può indicare un problema di prestazioni, che è solo nel contesto di se si tratta di un meccanismo efficiente per il raggiungimento degli obiettivi della query.Parlando come un data warehouse e BI ragazzo, il mio numero è un indicatore di avviso per le prestazioni è un indice basato il metodo di accesso e un ciclo nidificato.

Così, per il meccanismo di come leggere un piano di spiegare la documentazione di Oracle è una buona guida: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009

Buona lettura attraverso l'Ottimizzazione delle Prestazioni di Guida.

Anche google per la "cardinalità feedback", una tecnica in cui spiega il piano può essere utilizzato per confrontare le stime di cardinalità nelle varie fasi di una query con l'attuale cardinalità sperimentato durante l'esecuzione.Wolfgang Breitling è l'autore del metodo, credo.

Così, la linea di fondo:comprendere i meccanismi di accesso.Capire il database.Capire l'intenzione della query.Evitare di regole di pollice.

Altri suggerimenti

Questo soggetto è troppo grande per rispondere a una domanda come questa.Si dovrebbe prendere il tempo di leggere Oracle Ottimizzazione delle Prestazioni di Guida

I due esempi che seguono mostrano una scansione COMPLETA, e una scansione VELOCE utilizzando un INDICE.

È meglio concentrarsi sul Costo e Cardinalità.Osservando gli esempi l'uso dell'indice riduce il Costo dell'esecuzione della query.

È un po ' più complicato (e non ho il 100% di una maniglia su di esso), ma, fondamentalmente, il Costo è una funzione di CPU e i / o di costo, e la Cardinalità è il numero di righe Oracle prevede di analizzare.Riduzione di questi è una buona cosa.

Non dimenticare che il Costo di una query può essere influenzato dalla query e l'ottimizzatore di Oracle modello (es.:COSTO, SCEGLI ecc) e come spesso si esegue le statistiche.

Esempio 1:

SCANSIONE http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

Esempio 2: utilizzo di Indici:

INDICE http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

E come già suggerito, guardare fuori per la SCANSIONE della TABELLA.In genere è possibile evitare questi.

Alla ricerca di cose come scansioni sequenziali possono essere un po ' utile, ma la realtà è nei numeri...tranne quando i numeri sono solo stime!Ciò che di solito è lontano più utile che guardare una query piano guarda l'effettivo esecuzione.In Postgres, questa è la differenza tra SPIEGARE e SPIEGARE ANALIZZARE.SPIEGARE ANALIZZARE in realtà esegue la query, e diventa reale informazioni di temporizzazione per ogni nodo.Che ti permette di vedere cosa c'è in realtà succede, invece di ciò che il progettista pensa accadrà.Molte volte troverete che un'analisi sequenziale non è un problema, invece è qualcosa di diverso nella query.

L'altra chiave è identificare quali sono le effettive costoso passo.Molti strumenti grafici utilizzare diverse dimensioni delle frecce per indicare quanto diverse parti del piano dei costi.In questo caso, basta guardare i passaggi che hanno sottili frecce in arrivo e una grossa freccia lasciando.Se non si utilizza una GUI devi bulbo oculare i numeri e cercare dove improvvisamente molto più grande.Con un po ' di pratica si diventa abbastanza facile individuare le aree problematiche.

Veramente per problemi come questi, la cosa migliore da fare è ASKTOM.In particolare, la sua risposta a questa domanda contiene collegamenti a il in linea di Oracle doc, dove un sacco di questi tipi di regole sono spiegato.

Una cosa da tenere a mente, è che spiegare i piani sono veramente ipotesi.

Sarebbe una buona idea per imparare ad usare sqlplus, e sperimentare con il AUTOTRACE comando.Con alcuni numeri duri, generalmente, è possibile prendere decisioni migliori.

Ma si dovrebbe ASKTOM.Lui sa tutto su di esso :)

L'uscita di spiegare ti dice quanto tempo ogni fase ha preso.La prima cosa è trovare i passaggi che hanno preso un lungo periodo di tempo e capire cosa significano.Cose come una sequenza di scansione per indicare che è necessario migliorare l'indicizzazione - è soprattutto una questione di ricerca nel tuo database in particolare e di esperienza.

Un "Oh no, che non è di destra" è spesso in forma di scansione della tabella.L'analisi della tabella non utilizzano particolari indici e possono contribuire all'eliminazione di ogni utile nella memoria cache.In postgreSQL, per esempio, troverete questo aspetto.

Seq Scan on my_table  (cost=0.00..15558.92 rows=620092 width=78)

A volte l'analisi della tabella sono ideali su, ad esempio, utilizzando un indice di query le righe.Tuttavia, questa è una di quelle, con la bandiera rossa modelli che sembrano essere alla ricerca di.

Fondamentalmente, è necessario dare un'occhiata a ogni operazione e vedere se le operazioni di "senso", data la vostra conoscenza di come si dovrebbe essere in grado di lavorare.

Per esempio, se siete a partecipare a due tabelle A e B sulle rispettive colonne C e D (A. C=B. D), e il piano mostra un clustered index scan (SQL Server termine-non si è sicuri di oracle termine) nella tabella A, quindi un nested loop join, per una serie di indice cluster cerca tabella B, si potrebbe pensare che c'è stato un problema.In tale scenario, si potrebbe pensare che il motore per fare un paio di scansioni di indice (oltre gli indici delle colonne collegate) seguito da un merge join.Ulteriori indagini potrebbero rivelare male statistiche rendendo l'ottimizzatore sceglie che uniscono modello, o di un indice che in realtà non esiste.

guardate la percentuale di tempo trascorso in ciascuna sottosezione del piano, e considerare che il motore sta facendo.per esempio, se si esegue la scansione di una tabella, inserire un indice sul campo(s), è alla ricerca di

Io principalmente cercare indice o scansioni.Questo di solito mi dice che mi manca un indice su un'importante colonna in cui la dichiarazione o l'istruzione join.

Da http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx:

Se si verifica uno dei seguenti in un piano di esecuzione, si dovrebbe considerare li segnali di avvertimento e di indagare loro potenziale di prestazioni problemi.Ognuno di loro sono meno di ideale da un 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 per evitare di questi, ma più si può evitare di loro, il più veloce le prestazioni delle query sarà.

Regole di Pollice

(probabilmente si desidera leggere i dettagli troppo:

Male

L'analisi della tabella di Diverse Tabelle di Grandi dimensioni

Buona

Utilizzando un indice univoco
Indice comprende tutti i campi richiesti

Più Comuni Vincere

In circa il 90% dei problemi di prestazioni che ho visto, il più facile vincere è quello di rompere una query con un sacco (4 o più) tabelle in 2 query più piccole e una tabella temporanea.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top