自打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，一方面还研究昂贵的企业版。真.矫情！