Execution Plan
The physical strategy chosen by a database optimizer to access data, join relations, sort, aggregate, and execute a query.
Database Context
An execution plan is the physical strategy selected by the optimizer for scans, joins, sorting, aggregation, and other query operators. Costs for index access, full scans, nested loops, hash joins, and sorts depend heavily on cardinality estimates.
Runtime Boundary
A plan shown by an explain facility does not always reproduce every runtime condition. Bind values, adaptive behavior, cached state, parallelism, and actual row counts can make execution differ from a static estimate; estimated-versus-actual rows are therefore an important diagnostic comparison.
Related Database Concepts
- Cardinality Estimation
- Index Selectivity
- Prepared Statement
- Query Optimizer
Estimated Plan and Runtime Evidence Are Different Data
An optimizer plan is the output of a cost model; if cardinality estimation is wrong, the probability of choosing an appropriate physical operator also deteriorates. Asking only "did it use an index?" is therefore insufficient for most performance investigations. Join order, access path, and operator choice should be examined together with the gap between estimated and actual rows.
In Oracle, a plan written by EXPLAIN PLAN and runtime evidence obtained for an executed cursor through DBMS_XPLAN.DISPLAY_CURSOR are not the same observation. Bind values, adaptive behavior, cached state, and runtime statistics can change the execution context. Oracle documents these plan-display mechanisms directly in the SQL Tuning Guide. Related concept: Cardinality Estimation.