it-swarm.it

Come si interpreta il piano esplicativo di una query?

Quando si cerca di capire come viene eseguita un'istruzione SQL, a volte si consiglia di consultare il piano esplicativo. Qual è il processo da seguire nell'interpretazione (senso) di un piano esplicativo? Cosa dovrebbe distinguersi come "Oh, sta funzionando magnificamente?" contro "Oh no, non è vero."

87
user290

Rabbrividisco ogni volta che vedo commenti che i piani di lettura completi sono cattivi e l'accesso all'indice è buono. Scansioni di tabelle complete, scansioni dell'intervallo di indici, scansioni rapide di indici completi, loop annidati, unire 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 una conclusione significativa.

Una scansione completa è semplicemente il modo più efficiente di leggere 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, è solo nel contesto se si tratta di un meccanismo efficiente per raggiungere gli obiettivi della query. Parlando come data warehouse e ragazzo BI, il mio flag di avvertimento numero uno per le prestazioni è un metodo di accesso basato su indice e un ciclo nidificato.

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

Leggi anche la Guida all'ottimizzazione delle prestazioni.

Hanno anche un google per il "feedback sulla cardinalità", una tecnica in cui un piano esplicativo può essere utilizzato per confrontare le stime della cardinalità nelle varie fasi di una query con le cardinalità effettive sperimentate durante l'esecuzione. Wolfgang Breitling è l'autore del metodo, credo.

Quindi, linea di fondo: capire i meccanismi di accesso. Comprendi il database. Comprendi l'intenzione della query. Evita le regole empiriche.

78
David Aldridge

Questo argomento è troppo grande per rispondere a una domanda come questa. Dovresti prenderti del tempo per leggere Oracle's Performance Tuning Guide

13
Tony Andrews

I due esempi seguenti mostrano una scansione COMPLETA e una scansione VELOCE usando un INDICE.

È meglio concentrarsi su costi e cardinalità. Guardando gli esempi l'uso 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 della CPU e IO e la cardinalità è il numero di righe Oracle si aspetta di analizzare. Ridurre entrambi è una buona cosa.

Non dimenticare che il costo di una query può essere influenzato dalla query e dal modello di ottimizzatore Oracle (ad esempio: COSTO, SCEGLI ecc.) E dalla frequenza con cui esegui le tue statistiche.

Esempio 1:

SCAN 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.

5
Mark Nold

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 è solitamente lontano più utile che guardare una query piano è guardare il reale esecuzione . In Postgres, questa è la differenza tra EXPLAIN e EXPLAIN ANALYZE. EXPLAIN ANALYZE esegue effettivamente la query e ottiene informazioni di temporizzazione reali per ogni nodo. Ciò ti consente di vedere cosa sta succedendo , invece di quello che pensa il pianificatore accadrà. Molte volte scoprirai che una scansione sequenziale non è affatto un problema, invece è qualcos'altro nella query.

L'altra chiave è identificare quale sia il passo costoso effettivo. Molti strumenti grafici useranno frecce di dimensioni diverse per indicare il costo di diverse parti del piano. In tal caso, basta cercare i passaggi con frecce sottili in arrivo e una freccia spessa in uscita. Se non stai utilizzando una GUI, dovrai controllare i numeri e cercare dove diventano improvvisamente molto più grandi. Con un po 'di pratica diventa abbastanza facile individuare le aree problematiche.

4
decibel

Davvero per problemi come questi, la cosa migliore da fare è ASKTOM . In particolare la sua risposta a questa domanda contiene collegamenti al documento Oracle online, in cui sono spiegate molte di queste regole.

Una cosa da tenere a mente è che spiegare i piani è davvero la migliore ipotesi.

Sarebbe una buona idea imparare a usare sqlplus e sperimentare il comando AUTOTRACE. Con alcuni numeri concreti, puoi generalmente prendere decisioni migliori.

Ma dovresti ASKTOM. Ne sa tutto :)

3
EvilTeach

L'output della spiegazione indica quanto tempo ha richiesto ogni passaggio. La prima cosa è trovare i passaggi che hanno impiegato 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 particolare database ed esperienza.

2
Tom Leys

Un "Oh no, non è vero" è spesso sotto forma di scansione della tabella. Le scansioni di tabelle non utilizzano indici speciali e possono contribuire all'eliminazione di ogni utile 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 delle tabelle sono ideali, ad esempio, utilizzando un indice per interrogare le righe. Tuttavia, questo è uno di quei modelli di bandiera rossa che sembra stia cercando.

2
convex hull

Fondamentalmente, dai un'occhiata ad ogni operazione e vedi se le operazioni "hanno un senso" data la tua conoscenza di come dovrebbe essere in grado di funzionare.

Ad esempio, se si uniscono due tabelle, A e B sulle rispettive colonne C e D (AC = BD) e il piano mostra una scansione dell'indice cluster (termine di SQL Server - non sicuro del termine Oracle) sulla tabella A, quindi un loop nidificato si unisce a una serie di ricerche di indici cluster nella tabella B, si potrebbe pensare che si sia verificato un problema. In quello scenario, ci si potrebbe aspettare che il motore esegua una coppia di scansioni dell'indice (sugli indici nelle colonne unite) seguite da un'unione unita. Ulteriori indagini potrebbero rivelare statistiche errate che inducono l'ottimizzatore a scegliere quel modello di join o un indice che in realtà non esiste.

2
Jonathan Rupp

guarda la percentuale di tempo trascorso in ogni sottosezione del piano e considera cosa sta facendo il motore. ad esempio, se sta eseguendo la scansione di una tabella, prendere in considerazione la possibilità di inserire un indice nei campi per i quali si sta eseguendo la scansione

1
Steven A. Lowe

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 in uno dei piani di esecuzione viene visualizzato uno dei seguenti elementi, è necessario considerare i segnali di avvertimento e indagare per potenziali problemi di prestazioni. Ognuno di essi è 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, maggiori saranno le prestazioni della query.

1
dpollock