如何用提示改变查询的执行计划？

小比例尺

原帖由 mihawk 于 2008-4-7 17:26 发表
我认为可能的原因有两个,

1. 因为你使用的是常量来查询, 所以cbo会使用直方图来估算会得到多少笔记录, 从而计算使用index的cost是多少, 这个时候如果直方图不准确, 可能就会导致计算出来的索引扫描成本高于table scan的成本, 最后cbo就会选择成本较低的table scan.

2.直方图是准确的, 确实你这个sql返回的记录集很大, 应该走table scan更合理.这个可以通过hint指定索引, set trace on来确定. 到底应该走索引还是应该走全表扫描.

不过可以简单估算一下, 20080301~20080310之间有64200笔记录, 索引扫描总成本为49885.
而20080301~20080320之间有183144笔记录, 如果简单按比例来算的话扫描成本是 49885/64200*183144=142307.
而cbo估算的全表扫描成本是90365.
所以cbo选择了全表扫描, 成本9w, 比索引扫描的成本14w要小.

你好，请教一个问题。如果一个列唯一，那么在这个列上做直方图统计有意义吗？
谢谢

mihawk

原帖由 小比例尺 于 2008-4-7 17:31 发表


你好，请教一个问题。如果一个列唯一，那么在这个列上做直方图统计有意义吗？
谢谢

直方图的存在, 我的理解是, 把列上的值的分布情况告诉cbo, 而且通常是因为这个列上的值分布并不均匀.
如果一个列唯一, 统计直方图没有意义.
因为user_tab_columns里的density, num_rows,low_value,high_value就足以描述这个字段的值的分布情况了.

remen

原帖由 mihawk 于 2008-4-7 17:26 发表
我认为可能的原因有两个,

1. 因为你使用的是常量来查询, 所以cbo会使用直方图来估算会得到多少笔记录, 从而计算使用index的cost是多少, 这个时候如果直方图不准确, 可能就会导致计算出来的索引扫描成本高于table scan的成本, 最后cbo就会选择成本较低的table scan.

2.直方图是准确的, 确实你这个sql返回的记录集很大, 应该走table scan更合理.这个可以通过hint指定索引, set trace on来确定. 到底应该走索引还是应该走全表扫描.

不过可以简单估算一下, 20080301~20080310之间有64200笔记录, 索引扫描总成本为49885.
而20080301~20080320之间有183144笔记录, 如果简单按比例来算的话扫描成本是 49885/64200*183144=142307.
而cbo估算的全表扫描成本是90365.
所以cbo选择了全表扫描, 成本9w, 比索引扫描的成本14w要小.

mihawk

我又重新分析了lz提供的数据, 发现问题可能出在另一个地方.
那就是cbo对全表扫描成本的计算.
应该说cbo计算出的cost跟实际执行时trace的逻辑读应该是线性关系的,
就是说cost大的执行计划, 实际执行的逻辑读多.
但是看如下的数据:
索引扫描 的cost为 49885  ,逻辑读为 49013  consistent gets.
全表扫描 的cost为 90365, 按照比例的话, 逻辑读应该在9w左右, 但是实际执行全表扫描的逻辑读却是 417438  consistent gets.

而全表扫描成本=表的数据块数/多块读取数 (user_Tables.blocks / db_file_multiblock_read_count)
所以我怀疑user_tables.blocks这个统计信息没有反应当前table的真实情况.
有可能是装载大量数据后没有重新分析table的统计信息.