Histograms

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

I3_A r4v%s0qE:X7k7301064

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

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

当该字段数据并没有发生skewed状况时ITPUB个人空间0xc:I+ch.j
当该字段很少用来做查询where条件时

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

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

ITPUB个人空间G.I5PeN.d3m

在正常的数据分布而是没有数据的某种分布偏差的情况下，如果收集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/7301064/viewspace-442595/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7301064/viewspace-442595/