ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 关于histograms

关于histograms

原创 Linux操作系统 作者:sakuy 时间:2008-05-23 14:57:28 0 删除 编辑

什么时候需要使用Histograms?如果表格内有20column,其中最常被使用在查询的where条件句内的只有一个column A,另外有个column B很少被拿来做查询条件使用。现在你发现字段A和字段B的储存数据非常的skewed,就是假设储存的一百万笔rows,有99%的值相等,只有1%的值是零散的,这就叫做歪斜的储存值。


了解了skewed后,回到问题就是两个字段AB储存的值都是非常不平均,这时候optimizer很难准确的评估一个query statement所产生执行计划的最佳选择性。所以我们可以利用Histograms来帮助optimizer选择最适当的选择计划。他的意义简单的说就是假设有一袋米,里面有成千上万个寿司米,和混杂1%的在来米、中兴米、糯米等,当我查询为select * from 米袋 where 品种 = 寿司米,应该采用full table scan或者使用建立在品种字段上的索引?这个范例显然使用FTS是比较有效率的,但为了帮助optimizer了解,我们拿了75个篮子,我们把所有的米平均且依照品种依序放在75个篮子内,你可以很轻易看出除了几篮的在来米、中兴米之外,绝大部分装的都是寿司米,这就是建立histograms的目的。

回到一开始的问题,字段AB都是highly-skewed data,唯一差别是我们很少利用字段B在做查询条件句,那需要只对字段A建立histograms或者两者皆要,又或者表格内所有的字段都应该需要建立,才能更加提升效能呢?

当该字段数据并没有发生skewed状况时
当该字段很少用来做查询where条件时

我们不需要在该字段建立histograms,就算建了也不会对performance有所提升。

DBMS_STATS.GATHER_TABLE_STATS (NULL,'EMP', method_opt => 'FOR COLUMNS sal SIZE 100'); size指的是buckets数量,白话的就是建几个篮子来装,越多当然相对的平均,不过要看你数据特性来决定不是越大越好,可以尝试的调整来找出最佳的值,默认值是75


在正常的数据分布而是没有数据的某种分布偏差的情况下,如果收集histograms统计信息,在cursor_sharing这个参数设置为similar的时候容易出现cursor的子版本过多的问题。所以在使用histograms的时候需要注意这个问题。 

之所以产生这样的原因是这样的:在使用收集histogram统计数据之后,如果使用使用绑定变量,histogram数据将不会被使用。在我们设置参数cursor_sharing有三种选择:如果是force的时候,这时候,Oracle会将SQL文的变量无论三七二十一就变成需要的绑定变量的形式,这样我们采集的histogram数据将不会被使用。也就达不到我们所需要的优化效果了。如果设置为exact的时候,就会被不使用绑定变量,如果自己本身没有绑定变量的时候,如果设置为similar的时候,每一次优化器会根据histogram统计数据解析SQL,以达到最优的结果。但是如果这个数据的分布并不是有分布不均得现象,就不要使用histogram统计数据,这或许是为什么在Oracle的文档中说:

Do not use histograms unless they substantially improve performance.

的其中一个原因之一了。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10687260/viewspace-310025/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-04-20

  • 博文量
    14
  • 访问量
    23630