Oracle Full Hint - 编程之家

如何解决Oracle Full Hint

| 如果我正确理解文档；完整提示应强制执行全表扫描。在以下情况下，它不会执行相同的操作；在其上创建的索引中的数字。

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 |
-------------------------------------------------------------------------

我了解我正在选择一个存储在索引中的值。添加任何其他列将使扫描成为完整扫描。因此，我不得不问明显的问题。提示是对优化程序的请求还是命令？附带说明一下，统计的计算与优化有什么关系。索引的统计信息是自动更新还是明确的操作？

解决方法

我还没有测试过，但是使用提示的正确语法是：

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

它是斜杠加星号的空格。 , 附带说明，统计计算必须做什么优化。是统计自动更新的索引或这是显式操作吗？\“ 一个问题可能值得考虑（它肯定比您的主要问题:-D更相关）。 Oracle不会自动维护我们所有对象的100％统计信息。在10g之前，我们必须使用DBMS_STATS.GATHER _％_ STATISTICS明确安排后台作业来执行此操作。从11g开始，Oracle更改了默认行为。它监视针对架构发出的DML，并在现有统计信息过时时运行作业以收集对象的统计信息。即使这样，它也只计算行百分比的统计信息。通常这足够好了，尤其是对于大型表，这时检查所有行会很昂贵。此默认行为本身通常是“足够好”。如果查询计划不好，可能值得收集新的统计信息，也许是针对较大的行样本。但您不必像许多地方那样，不得不定期收集针对您整个架构的完整统计信息。大多数时候，您可能只是在浪费CPU周期，并且冒着破坏一些现有计划的风险。数据库统计是一个大话题。《性能调优指南》上有一整章。了解更多。另外，请阅读PL / SQL软件包指南以获取有关DBMS_STATS本身的更多信息。