刚看官方文档看到的，感觉比较有意思，摘出来。
原文地址：
8.2.2 Full Table Scans
A full table scan reads all rows from a table, and then filters out those rows that do not meet the selection criteria.
This section contains the following topics:
- When the Optimizer Considers a Full Table Scan
In general, the optimizer chooses a full table scan when it cannot use a different access path, or another usable access path is higher cost. - How a Full Table Scan Works
In a full table scan, the database sequentially reads every formatted block under the high water mark. The database reads each block only once. - Full Table Scan: Example
This example scans thehr.employeestable.
Parent topic: Table Access Paths
8.2.2.1 When the Optimizer Considers a Full Table Scan
In general, the optimizer chooses a full table scan when it cannot use a different access path, or another usable access path is higher cost.
The following table shows typical reasons for choosing a full table scan.
Table 8-2 Typical Reasons for a Full Table Scan
| Reason | Explanation | To Learn More |
|---|---|---|
| No index exists. |
If no index exists, then the optimizer uses a full table scan. |
|
| The query predicate applies a function to the indexed column. |
Unless the index is a function-based index, the database indexes the values of the column, not the values of the column with the function applied. A typical application-level mistake is to index a character column, such as |
"Guidelines for Using Function-Based Indexes for Performance" |
| A |
The optimizer cannot use the index to count the number of table rows because the index cannot contain null entries. |
"B-Tree Indexes and Nulls" |
| The query predicate does not use the leading edge of a B-tree index. |
For example, an index might exist on |
"Index Skip Scans" |
| The query is unselective. |
If the optimizer determines that the query requires most of the blocks in the table, then it uses a full table scan, even though indexes are available. Full table scans can use larger I/O calls. Making fewer large I/O calls is cheaper than making many smaller calls. |
|
| The table statistics are stale. |
For example, a table was small, but now has grown large. If the table statistics are stale and do not reflect the current size of the table, then the optimizer does not know that an index is now most efficient than a full table scan. |
"Introduction to Optimizer Statistics" |
| The table is small. |
If a table contains fewer than n blocks under the high water mark, where nequals the setting for the |
|
| The table has a high degree of parallelism. |
A high degree of parallelism for a table skews the optimizer toward full table scans over range scans. Query the value in the |
|
| The query uses a full table scan hint. |
The hint |
Parent topic: Full Table Scans
8.2.2.2 How a Full Table Scan Works
In a full table scan, the database sequentially reads every formatted block under the high water mark. The database reads each block only once.
The following graphic depicts a scan of a table segment, showing how the scan skips unformatted blocks below the high water mark.
Because the blocks are adjacent, the database can speed up the scan by making I/O calls larger than a single block, known as a multiblock read. The size of a read call ranges from one block to the number of blocks specified by the DB_FILE_MULTIBLOCK_READ_COUNT initialization parameter. For example, setting this parameter to 4 instructs the database to read up to 4 blocks in a single call.
The algorithms for caching blocks during full table scans are complex. For example, the database caches blocks differently depending on whether tables are small or large.
See Also:
-
Oracle Database Concepts for an overview of the default caching mode
-
Oracle Database Reference to learn about the
DB_FILE_MULTIBLOCK_READ_COUNTinitialization parameter
Parent topic: Full Table Scans
8.2.2.3 Full Table Scan: Example
This example scans the hr.employees table.
The following statement queries monthly salaries over $4000:
SELECT salary
FROM hr.employees
WHERE salary > 4000;
Example 8-1 Full Table Scan
The following plan was retrieved using the DBMS_XPLAN.DISPLAY_CURSOR function. Because no index exists on the salarycolumn, the optimizer cannot use an index range scan, and so uses a full table scan.
SQL_ID 54c20f3udfnws, child number 0
-------------------------------------
select salary from hr.employees where salary > 4000
Plan hash value: 3476115102
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 3 (100)| |
|* 1 | TABLE ACCESS FULL| EMPLOYEES | 98 | 6762 | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("SALARY">4000)Parent topic: Full Table Scans
END