甲骨文为什么使用DBMS_STATS.GATHER_TABLE_STATS？

Question

我找到了一些文档，解释Oracle使用这些来进行性能调优等，但并不是很清楚它到底做了什么。

有没有人能用非常简单的例子给我解释一下？

Answer 1

大多数企业数据库(包括Oracle )都使用基于成本的优化器来确定给定SQL语句的适当查询计划。这意味着优化器使用有关数据的信息来确定如何执行查询，而不是依赖规则(这就是较早的基于规则的优化器所做的事情)。

例如，假设一个简单的bug跟踪应用程序有一个表

CREATE TABLE issues (
  issue_id number primary key,
  issue_text clob,
  issue_status varchar2(10)
);

CREATE INDEX idx_issue_status
    ON issues( issue_status );

如果我是一家大公司，这个表中可能有一百万行。其中，100个的issue_status为ACTIVE，10,000个issue_status为QUEUED，989,900个状态为COMPLETE。如果要对表运行查询以查找活动问题

SELECT *
  FROM issues
 WHERE issue_status = 'ACTIVE'

优化器有一个选择。它可以使用issue_status上的索引，然后针对索引中匹配的每一行在表中执行单行查找，也可以在issues表上执行表扫描。哪个计划更有效将取决于表中的数据。如果Oracle希望查询返回表中的一小部分数据，那么使用索引会更有效率。如果Oracle希望查询返回表中的大部分数据，那么表扫描会更有效。

DBMS_STATS.GATHER_TABLE_STATS收集的统计数据使Oracle能够做出这一决定。它告诉Oracle表中大约有100万行，issue_status列有3个不同的值，数据分布不均匀。因此，Oracle知道对查询使用索引来查找所有活动问题。但它也知道，当你转过身来，试图寻找所有已解决的问题时

SELECT *
  FROM issues
 WHERE issue_status = 'CLOSED'

表扫描会更有效率。

收集统计信息允许查询计划随着数据量和数据分布的变化而随时间变化。当您第一次安装问题跟踪器时，您将只有很少的已完成问题，而更多的是活动和排队的问题。随着时间的推移，完成的问题数量上升得更快。当您在表中获得更多行，并且处于各种状态的行的相对比例发生变化时，查询计划也会发生变化，因此，在理想情况下，您总是可以获得最有效的计划。