让我们回到9i版本出现之前，回顾一下数据库应用和查询调优。我看到论坛里越来越多的帖子在询问那些冗长又无用的任务存在的意义。在本文中，就让我们来看看，哪些所谓的调优是没有必要做的。

定期索引重建

大多数情况下，DBA都在忙于进行索引重建。是的，他们可以对埋在索引树中空的索引块进行“大扫除”。但索引会再次生长到重建前的大小，另外空指数块也将再次分散在索引树中，所以我不明白定期执行重建索引的意义所在。事实上，对于非分区索引，我认为完全没有重建的必要，原因如下：

• 重建索引会对表和索引加锁，直到重建完成
• 会致使游标无效
• 没有实际用处

是的，有些时候分区表上的本地索引需要重建，但这通常是在分区表进行DDL(删除分区，添加/分割分区，交换分区)操作后进行的。DDL操作会使得本地分区索引不能使用，所以它们才需要被重建。这不是一个“容量”问题造成的，也不是一个“性能”问题造成的，只是因为索引无法使用，将会干扰到表的访问和生产过程而已。但令人担忧的是，即使MOS已经撤下了原来的关于何时重建索引的文档，取而代之的是一个更负责任的版本，也更好的解决了这一问题，但DBA决定是否执行重建索引时却依然依据过时的原则，如根据b -树深度或索引大小来决定。仍然有很多DBA坚定地使用计划任务或DBMS_SCHEDULER在一周或一月内进行一次索引重建，他们深信这样能够提高性能，加快生产过程。事实并不是这样，这只会在索引重建时给用户的使用带来不便。因为大多数应用程序表存在多个索引，对于一个给定的表，重建索引可以花费几个小时的时间，而且整个过程中数据表都处于锁定状态，生产过程基本停止。我不认为这对提高性能有任何的帮助。

不断调整数据库参数

有一些DBA似乎总是不满意数据库的性能，他们不断寻找问题所在，而不管该问题是否真的对性能造成了影响。这通常被称为强迫性调优障碍(下文简称CTD）CTD造成了一个循环，现在调整这个，一会调整别的，这些调整仅仅是基于统计数据的微小变化。对于DBA来说，CTD非常浪费时间。并不是每一个延迟统计都需要完美的调整，这在现实世界是不可能的。一切都可以归结为DBA所认为的性能与终端用户考虑性能是不同的。在CTD影响下，DBA认为一切都是潜在的问题，即使这些问题并不影响终端用户的体验。终端用户方面，当他们花费了比预期更长的时间，他们才会认为性能有问题。一旦终端用户的问题被解决，优化就应该停止，因为进一步调整并不会提供任何额外的好处。在生产系统中延迟统计数据并不会是完美的，多用户访问和修改数据会导致并发等待，无论多么短，在这方面进行调优以期待完美的响应时间是毫无用处的，CTD，让DBA转变为一个吹毛求疵的人，虽然花费大量时间努力调整的参数，却并没有影响实际的系统性能，老实说，这毫无用处。

表重组

随着表容量越来越大，查询访问数据需要更长的时间才能完成，特别是在查询需要遍历全表才能获取所需数据的情况下。仍有一些DBA坚信重组表数据会对提高性能有很大的帮助。其中一个重组思想就是对表数据进行排序，改善集群因子。是的，计算索引的聚集因子基于表元素“位置”与排序索引键的相对关系，但“改善”某一个索引的聚集因子通常会对表中其他索引的聚集因子造成不良影响。另一个问题是，这些表属于堆机构，并未存在实际的数据顺序，你可以在表中任何空数据块上插入数据。数据的有序性只会持续到第一个插入之后，此后表数据的索引再次分散。多年以前，供应商认为对数据排序是提高性能最好的方式，并“建议”其产品定期维护这个美妙的顺序。这个想法的问题在于，表数据可以按照一个索引进行排序，当终端用户处理数据数据时，它们又逐渐回归到其未排序时的状态。像CTD一样，这成为一个永无止境的循环，“排序，排序，排序，排序，排序”，人们认为这样会有好处。实际上却不能，因为每次数据排序时，生产系统呈现为不可用状态。如果终端用户不能工作，排序后的查询即使再快也没有任何用处。不幸的是，一旦DBA被这种排序蒙蔽，他们就难以意识到这些排序流程给用户带来的不便。终端用户需要工作，而不是一直等待DBA完成数据排序，在一段时间后再返回一个未排序结果。DBA应该努力创建有意义和持久性改变来提高性能；查询调优，计划稳定和索引分析才是有意义的方式，他们能够带来实实在在的好处，且持续时间也远远超过了创建它们时所消耗的时间。

DBA浪费时间的例子还不仅于此，在此就不再一一列举。知道该做什么和能做些什么是一个伟大DBA的标志。再次阅读本文介绍的这些要点，应该能够引导你完成有意义的调优任务，这些任务的效果持久，且不需要持续的关注或重复执行。当然，没有任何东西是完美的，特别是你的数据库，所以不要为了追求完美而让你无休止的忙碌于调优工作中。有很多真正需要DBA来完成的日常工作。不要陷入细节中无法自拔，它并不值得你付出努力。