Oracle完整提示

Question

如果我正确理解文档 ; 完整提示应强制进行全表扫描.在下面的场景中,它没有执行相同的操作;

Num就像在其上创建的索引一样.

SQL> desc test;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 NUM                                       NOT NULL NUMBER
 NUM2                                               NUMBER(10)
 NUM3                                               NUMBER

查询:

select num from test;

结果:

       NUM
----------
         1
         2

执行计划

Plan hash value: 410557223

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      |     2 |     4 |     1   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | ID   |     2 |     4 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------

查询:

select /* +full(test) */ num from test;

结果:

       NUM
----------
         1
         2

执行计划

Plan hash value: 410557223

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      |     2 |     4 |     1   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | ID   |     2 |     4 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------

我理解我正在选择存储在索引中的值.添加任何其他列使扫描完整.因此我不得不问明显的.是提示请求还是优化器的命令？

另一方面,统计计算与优化有什么关系.索引的统计信息是自动更新还是显式操作？

Answer 1

我没有测试过这个,但使用提示的正确语法是:

select /*+ full(test) */ num from test;

它是斜线加星空间.

Answer 2

"另一方面,统计计算与优化有什么关系.索引的统计数据是自动更新还是显式操作？"

可能本身就有一个问题(它肯定比你的主要问题更有意义:-D).

Oracle不会自动为所有对象维护100%的统计信息.在10g之前,我们必须使用DBMS_STATS.GATHER _%_ STATISTICS显式安排后台作业来执行此操作.

由于11g Oracle已经改变了默认行为.它监视针对模式发出的DML,并运行作业以在现有统计信息变得陈旧时收集对象的统计信息.即便如此,它只计算一定比例的行的统计数据.这通常是足够好的,特别是对于大型表,当检查所有行时会很昂贵.

此默认行为本身通常是足够好的.如果您遇到错误的查询计划问题,可能需要收集新的统计信息,可能需要针对更大的行样本.但是并不觉得有必要经常收集整个模式的完整统计数据,因为很多地方仍然这样做.大多数情况下,您可能只是浪费CPU周期,并且存在破坏某些现有计划的风险.

数据库统计是一个很大的主题.性能调优指南有一整章. 了解更多. 另外,请阅读PL/SQL包指南,了解有关DBMS_STATS本身的更多信息.