? 自打2003掉进某公司的DB维护项目组，到今天断断续续接触Oracle已经是十年了。尽管它依然是数一数二的RDBMS，但Oracle数据库在我这里的声望始终是仇恨。这次遇到的性能调试如下：

?

? 一个业务表，数据级别在千万行，检索条件只有一个业务年月字段，但是有多达十个的group by，且掺杂了roll_up及cube。客户要调优建议。

?

? SQL文很简单，select where group by连个结合都没，索引也建了一大票。一方面受限于时间，环境和...一些因素，另一方面还是因为有趣，仅仅尝试了下面两个方向。

?

==============

= 并行

------------------

测试数据量较小，只找到个百万级别的，也贴了索引。

本地跑下SQL，只有大概10秒左右。

试着尝试并行，根本没变化！

?

尝试改变条件，估计是由于目标数据量的缘故，从index range scan变成了table access full。

再次尝试并行，有用了。并行度设置成3(本地虚拟机只4核)时，从120秒降到60秒。

SELECT ?/*+ parallel(tbl, 3) */ ... from tbl

尝试增加并行度，

- 4的时候最优。

- 6的时候开始下降。

听那老爷机发出的种种奇怪的呻吟声，想来是资源到了极限。

?

?

==============

= bitmap index

------------------

由于业务字段是年月，按道理讲基数(cardinality)应该比较小。5年共60个月除以千万，应该适合bitmap才对。

但加上后，效果不理想。结果如下

?

1. 只加bitmap —— 110秒加。

2. 只并行(度=4) —— 55秒加。

3. 并行 + bitmap —— 75秒加。

4. 无 —— 115秒加

?

查了下测试数据，百万条的测试数据里有150+的年月，按理讲基数也不大。可是效果如上，不给力！

我估摸着性能开销不在检索数据上，而是在统计上的缘故。

去掉统计，只留下检索时，并行就慢于bitmap。

?

?

除了上述的简单优化外，还提了些架构方面的建议，不过那是另个话题了。

?

?

注：这测试是在PC机上跑的VM进行的，差不多也就只能做个参考。

注：这两个功能都是需要企业版。正如M大人所言，一方面讨厌Oracle，一方面还研究昂贵的企业版。真.矫情！

?