关于oracle 11g的拓展统计信息

  最近迷上了数据库查询优化，那种把一两分钟的查询优化到几秒钟的快感，让我欲罢不能。

  从一开始的迷信各种语句的写法，到后面开始看执行计划，再到后来的扩展统计信息，一步一步感觉慢慢专业了起来。

  一开始在网上看，什么sql语句中不要使用or，要使用union all代替，否则优化器会放弃索引而使用全表扫描。对此我深信不疑，并将一个炒鸡长的sql硬生生的用union all拆成了两个，感觉速度可以大幅提升，但是实际结果却让我一脸懵逼，速度根本没啥变化嘛。由于当时还不会看执行计划，这个疑问困惑了我好一段时间。

  后来开始使用执行计划，发现原来的那个用or的sql可以走索引啊，根本没啥问题嘛，所以就继续查找原因，最终得到的答案是：只有不恰当的使用or才会导致优化器放弃使用索引而全表扫描。呃...这让我再也不轻易相信百度出来的结果了，实践才是检验真理的唯一标准，人家说的啥先测试一发再下定论也不晚嘛。

  类似的还有什么不要使用<>号呀，使用exists代替in呀等等。

  好吧，扯了那么多，还没有聊到标题写的扩展统计信息。

  这个拓展统计信息是最近看的oracle嘉年华的视频中提到的，观看过那个视频之后得到了如下的结论：

  1. 平时认为的要想快就建索引的想法是有条件的，索引只有在查出少量数据的时候好使，若和视频中一样要查出四千万数据使用索引就是在作死

  2. 还有就是要想查的快，正确的执行计划就很关键，那么如何让优化及做出更精准的代价估计就很重要了。

  在oracle 11g之前，如果一个表中的两个（多个）字段同时出现在一个where子句中，而且这两个列还有关联关系，

  eg:customer表中state字段与country字段同时出现在一个查询中：

         select a.* from customer a where a.state = '河北' and a.country = '中国';

   而在customer表中河北人占比0.2%，而中国人占比2%，那么优化器会简单粗暴的将结果估计为0.2%*2%，而实际结果则是0.2%，这结果差了多少就不言而喻了吧，这种错误的估计会使优化器做出错误的执行计划最终导致查询的缓慢。

  为了解决以上的情况，oracle 11g推出了扩展统计信息这一新特性，使用DBMS_STATS.CREATE_EXTENDED_STATS可以创建这两个列的扩展统计信息(可以看做一个虚拟列)。在创建扩展统计信息后的第一次查询，优化器还是会错误的估计- -!，这是因为查询并未真正使用我们创建的扩展统计信息（因为刚创建扩展统计信息而并未执行查询时时，并没有这个虚拟列的直方图，所以优化器使用了那两个真实列的直方图）。而当虚拟列有直方图之后，优化器就会使用它进行估计，并最终产生正确的执行计划！

  参考文章：https://blogs.oracle.com/optimizer/entry/extended_statistics