(11)好心办坏事的SQL优化

    前面已经说过在表上乱加不合理索引的问题，位图索引的问题等，但索引引起的问题实在太多了。我在这在说说另一种

关于索引的好心办坏事的SQL优化情形。

    话说某开发人员对索引非常重视，对索引花了很多时间研究，并在开发测试阶段为了让系统达到最好的效果，在SQL语句

中做了很多工作。其中之一，将认为最有效的索引固定在SQL语句中。所以在他写得代码中有大量的/*+ */ 存在。他希望一

劳永逸地解决性能问题。

      但应用上线后，实际效果并不全如人意。其中更有些SQL运行表现与测试中相差甚远。 原来他没有考虑到实际应用中，

有些表实际增长及变更情况远在预料之外。增长非常快，且有些更新也很频繁。虽然之前 测试时有做应用模拟。但又有几

个项目能说模拟得和真实环境差不多的？ 所以之前表现良好的SQL，在新形势下有些执行计 划已不太适应新情况了。

    这是典型的过早优化造成的后果。因为数据库的数据是在变化中的，所以最合理的执行计划也是跟着变化的。这也是Oracle

推出自动化分析采集工具的原因之一。 随着数据量的更新，数据库统计信息的完善配合数据库越来越智能的CBO.数据库完全

能够在大多数情况下与时俱进地找到合适的执行计划，而这个执行计划不一定是你所指的那个索引。

    个人认为过早的固定索引，相当于过早的捆住自已的手脚。在开发阶段，可以依自己的分析建立相关的索引，但基本上无

须强制使用某个索引。如果一定要强制使用，可以在应用上线一段时间后，再加上也不迟。

     除了这个外，还一个索引重建的问题也很可怕。有人查到说，表在运行一段时间有过大量的增，删改之后，

导致索引中叶子行被删除，造成索引产生碎片。索引碎片越多，索引的I/O成本就越高，为了让索引有最好的性能。

他们很勤奋地给索引重建，以达到最佳速度。问题是太容易出问题了。由于在生产库上索引重建，搞死一个库，

或者一个大表索引重建花了几个小时甚至几天的等帖子 ITPUB上很多。 

  重建是要很小心的，不过有好消息是，11g 又增强了在线索引重建的特性,可以减少重建过程中对DML操作的阻塞。 

   例子:ALTER INDEX IDX_XCL REBUILD ONLINE; 

     SQL调优的水太深了，调优的书市面上出了一本又一本，我就不多说了，在这就先举这两个例子。

好像没有写证明的实例在上面，原因是我一下也想不到合适的，喷点口水就算了先。

MAIL:xcl_168@aliyun.com

Blog:http://blog.csdn.net/xcl168/