Rabbrividisco ogni volta che vedo commenti sul fatto che le scansioni complete delle tabelle non sono valide e l'accesso all'indice è buono. Scansioni complete di tabelle, scansioni di intervalli di indici, scansioni complete di indici rapidi, loop nidificati, 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 dello scopo di una query in per raggiungere una conclusione significativa.
Una scansione completa è semplicemente il modo più efficiente per leggere un'ampia parte dei blocchi di un segmento di dati (una tabella o una (sotto)partizione di una tabella) 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 in qualità di addetto al data warehouse e alla BI, il mio flag di avviso numero uno per le prestazioni è un metodo di accesso basato su indici e un ciclo nidificato.
Quindi, per il meccanismo su come leggere un piano di spiegazione, la documentazione 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.
Avere anche un google per il "feedback di cardinalità", una tecnica in cui un piano di spiegazione può essere utilizzato per confrontare le stime di cardinalità nelle 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. Comprendere il database. Comprendere l'intenzione della query. Evita le regole pratiche.
