Ik huiver als ik opmerkingen zie dat volledige tablescans slecht zijn en indextoegang goed. Volledige tabelscans, indexbereikscans, snelle volledige indexscans, geneste lussen, merge-joins, hash-joins enz. zijn eenvoudigweg toegangsmechanismen die door de analist moeten worden begrepen en gecombineerd met kennis van de databasestructuur en het doel van een query in om tot een zinvolle conclusie te komen.
Een volledige scan is simpelweg de meest efficiënte manier om een groot deel van de blokken van een datasegment (een tabel of een tabel(sub)partitie) te lezen, en hoewel het vaak kan wijzen op een prestatieprobleem, is dat alleen in de context of het een efficiënt mechanisme is om de doelen van de zoekopdracht te bereiken. Sprekend als een datawarehouse en BI-man, is mijn belangrijkste waarschuwingsvlag voor prestaties een op index gebaseerde toegangsmethode en een geneste lus.
Dus, voor het mechanisme van het lezen van een uitlegplan is de Oracle-documentatie een goede gids:http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009
Lees ook de Performance Tuning Guide goed door.
Heb ook een google voor "kardinaliteitsfeedback", een techniek waarbij een uitlegplan kan worden gebruikt om de schattingen van kardinaliteit in verschillende stadia in een query te vergelijken met de daadwerkelijke kardinaliteiten die tijdens de uitvoering worden ervaren. Wolfgang Breitling is de auteur van de methode, geloof ik.
Het komt er dus op neer:begrijp de toegangsmechanismen. Begrijp de databank. Begrijp de bedoeling van de query. Vermijd vuistregels.