为什么 oracle 不使用索引进行不同的查询？

Question

为什么 oracle 不使用索引进行不同的查询？

hak*_*aki 5 performance oracle optimization performance-tuning

这是场景

SQL> exec dbms_stats.gather_table_stats(user,'TM', cascade=>true)

PL/SQL procedure successfully completed.

SQL> SELECT SEGMENT_NAME , SEGMENT_TYPE , BYTES / 1024 / 1024 MB , BLOCKS FROM DBA_SEGMENTS WHERE SEGMENT_NAME IN ('TM', 'TM_LD_IX');

SEGMENT_NAME            SEGMENT_TYPE        MB        BLOCKS
------------------------------------------ ---------- ----------
TM                      TABLE                 296      37888
TM_LD_IX                INDEX                  46       5888

SQL> select index_name , column_name from user_ind_columns where index_name = 'TM_LD_IX';

INDEX_NAME   COLUMN_NAME
------------ ------------------------------
TM_LD_IX     LD

SQL> explain plan for select distinct LD from TM;

Explained.

SQL> @ex

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------------------

Plan hash value: 4241255022

--------------------------------------------------------------------------------------
| Id  | Operation          | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                 |   693 |  4158 |  7920   (8)| 00:01:36 |
|   1 |  HASH UNIQUE       |                 |   693 |  4158 |  7920   (8)| 00:01:36 |
|   2 |   TABLE ACCESS FULL| TM              |  2549K|    14M|  7486   (3)| 00:01:30 |
--------------------------------------------------------------------------------------

9 rows selected.

SQL> explain plan for select /*+ index(x , TM_LD_IX) */ distinct LD from TM x;

Explained.

SQL> @ex

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------------------

Plan hash value: 4241255022

--------------------------------------------------------------------------------------
| Id  | Operation          | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                 |   693 |  4158 |  7920   (8)| 00:01:36 |
|   1 |  HASH UNIQUE       |                 |   693 |  4158 |  7920   (8)| 00:01:36 |
|   2 |   TABLE ACCESS FULL| TM              |  2549K|    14M|  7486   (3)| 00:01:30 |
--------------------------------------------------------------------------------------

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for 32-bit Windows: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production

Run Code Online (Sandbox Code Playgroud)

如您所见，oracle 没有使用索引，LD而是选择了全表扫描。我什至不能让他使用带有历史记录的索引。

在上面的简单查询中，我希望索引快速完整扫描TM_LD_IX. mydb_file_multiblock_read_count设置为 32，所以我预计成本约为 5888 / 32 = 184（使用索引我还可以节省散列唯一值的成本）。

那么，我在这里错过了什么？

Answer 1

mir*_*173 10

这种行为的原因是在索引中找不到 LD 为 NULL 的行。因此Oracle 必须扫描全表。如果表是使用 LD 作为 NOT NULL 列创建的，则优化器使用此信息并执行 INDEX FAST FULL SCAN。如果向未为列 LD 定义 NOT NULL 的表添加“CHECK(LD is not null)”约束，则优化器不会使用约束提供的信息并再次进行全表扫描，即使您给了他一个提示。乔纳森刘易斯写了关于这种行为的文章。

以下脚本演示了 Oracle 11.2.0.3.0 的这种行为

*create_table.sql* 向表中插入数据并创建索引和统计信息

关闭自动跟踪
删除表对象
/
创建表对象（
  object_id 编号，
  所有者 varchar2(30),
  object_name varchar2(128),
  object_type varchar2(19)
)
/

插入对象（
  对象 ID，
  所有者，
  对象名称，
  对象类型
)
选择
  对象 ID，
  所有者，
  对象名称，
  对象类型
来自 dba_objects
/


在对象上创建索引 idx_object_id（object_id）；

exec dbms_stats.gather_table_stats(user,'objects',cascade=>true)

现在运行以下脚本：

线轴输出
关闭反馈
设置线宽 300
设置修剪
设置修剪轴

@create_table
设置自动跟踪 traceonly 解释

迅速的
提示 1. 没有约束的查询计划：
选择不同的 object_id
从对象；
rem ------------------------------------------------- ——

@create_table
更改表对象添加约束 nn_object_id 检查（object_id 不为空）验证；
设置自动跟踪 traceonly 解释

迅速的
提示 2. 带有检查约束的查询计划
选择不同的 object_id
从对象；
rem ------------------------------------------------- ——

@create_table
更改表对象修改 object_id 不为空；
设置自动跟踪 traceonly 解释

迅速的
提示 3.plan for query with NOT NULL 列
选择不同的 object_id
从对象；
rem ------------------------------------------------- ——

@create_table
在对象上创建位图索引bidx_object_type（object_type）
/
设置自动跟踪 traceonly 解释

迅速的
提示4.plan for query with bitmap index
选择不同的 object_type
从对象；
rem ------------------------------------------------- ——


线轴关闭

这给出了以下输出

1. 没有约束的查询计划：

执行计划
-------------------------------------------------- --------
计划哈希值：4077265613

-------------------------------------------------- -----------------------------
| 身份证 | 操作 | 姓名 | 行 | 字节 | 成本 (%CPU)| 时间 |
-------------------------------------------------- -----------------------------
| 0 | 选择语句 | | 59063 | 288K| 139(3)| 00:00:02 |
| 1 | 哈希唯一| | 59063 | 288K| 139(3)| 00:00:02 |
| 2 | 表访问已满| 对象 | 59063 | 288K| 136(0)| 00:00:02 |
-------------------------------------------------- -----------------------------


2. 使用检查约束的查询计划

执行计划
-------------------------------------------------- --------
计划哈希值：4077265613

-------------------------------------------------- -----------------------------
| 身份证 | 操作 | 姓名 | 行 | 字节 | 成本 (%CPU)| 时间 |
-------------------------------------------------- -----------------------------
| 0 | 选择语句 | | 59063 | 288K| 139(3)| 00:00:02 |
| 1 | 哈希唯一| | 59063 | 288K| 139(3)| 00:00:02 |
| 2 | 表访问已满| 对象 | 59063 | 288K| 136(0)| 00:00:02 |
-------------------------------------------------- -----------------------------


3. 计划使用 NOT NULL 列进行查询

执行计划
-------------------------------------------------- --------
计划哈希值：4172758181

-------------------------------------------------- -------------------------------------
| 身份证 | 操作 | 姓名 | 行 | 字节 | 成本 (%CPU)| 时间 |
-------------------------------------------------- -------------------------------------
| 0 | 选择语句 | | 59063 | 288K| 40 (8)| 00:00:01 |
| 1 | 哈希唯一| | 59063 | 288K| 40 (8)| 00:00:01 |
| 2 | 索引快速全扫描| IDX_OBJECT_ID | 59063 | 288K| 37 (0)| 00:00:01 |
-------------------------------------------------- -------------------------------------


4.plan for query with bitmap index

执行计划
-------------------------------------------------- --------
计划哈希值：2970019208

-------------------------------------------------- -----------------------------------------------
| 身份证 | 操作 | 姓名 | 行 | 字节 | 成本 (%CPU)| 时间 |
-------------------------------------------------- -----------------------------------------------
| 0 | 选择语句 | | 43 | 第387话 6 (34)| 00:00:01 |
| 1 | 哈希唯一| | 43 | 第387话 6 (34)| 00:00:01 |
| 2 | 位图索引快速全扫描| BIDX_OBJECT_TYPE | 59063 | 519K| 4 (0)| 00:00:01 |
-------------------------------------------------- -----------------------------------------------

概括

如果列上存在正常的 B*-tree 索引，则该列中可能存在 NULL 值，那么优化器不能仅依靠索引的信息来执行“选择区分”并使 TABLE ACCESS FULL。

如果在列上有一个正常的 B*-tree 索引和一个 NOT-NULL 检查约束，优化器也不依赖于索引的信息并且使 TABLE ACCESS FULL。

如果有一个正常的 B*-tree 索引并且该列被定义为 NOT NULL，那么优化器依赖于索引的信息并执行 INDEX FAS FULL SCAN。

如果列上有位图索引，则优化器知道所有信息都在索引中并执行 BITMAP INDEX FAST FULL SCAN

归档时间：	12 年，2 月前
查看次数：	12546 次
最近记录：	8 年，8 月前