In this example, there are no operations at the same level of indentation; therefore, you
read the order of operations from inside out. The first operation is the index range scan, followed
by the table access; the SELECT STATEMENT operation displays the output to the user. Each
operation has an ID value (the first column) and a parent ID value (the second number; it is blank
in the topmost operation). In more complex explain plans, you may need to use the parent ID
values to determine the order of operations.
This plan shows that the data returned to the user comes via a TABLE ACCESS BY INDEX
ROWID operation. The RowIDs are supplied by an index range scan of a unique index.
Each step is assigned a ???cost.??? The cost is cumulative, reflecting the cost of that step plus the
costs of all its child steps. You can use the cost values to identify steps that contribute the greatest
amount to the overall cost of the query and then target them for specific tuning efforts.
When evaluating the output of the explain plan command, you should make sure that the
most selective indexes (that is, the most nearly unique indexes) are used by the query. If a
nonselective index is used, you may be forcing the database to perform unnecessary reads to
resolve the query. A full discussion of SQL tuning is beyond the scope of this book, but you
should focus your tuning efforts on making sure that the most resource-intensive SQL statements
are using the most selective indexes possible.
Pages:
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424