DBA们应该将自己从“我要对什么调优?”的老路上解放出来，而在指标、配置和成本方面花费一定的时间。研究这些测量指标并做一个对根本原因的分析，而这将花费很多时间和精力。DBA都是聪明人，但很少在操作系统和DBMS系统性能调优上有发言权。

所以那个曾经需要花费10分钟 CPU时间的查询，在进行过调优之后，现在只需要几秒钟，这又如何呢?我们来考虑一些现实的例子。

假设DB2的配置参数SRTPOOL(排序池大小)设置太低。可能的结果就是SQL语句在请求排序 (即通过GROUP BY)时会因为排序池空间不足而出错。所以DBA告诉开发人员应该将ORDER BY从他们的查询中移除，然而自己对返回的结果进行排序来对查询进行“调优”。这算是调优么?

还有DBA发现一个查询要运行长达两小时，并且会消耗15分钟的CPU时间。接着DBA就对查询做了调优，现在它在10分钟的运行时间里占用10分钟的CUP时间。这么做有意义吗?那个查询原来只消耗12.5%的CPU，但是现在却要消耗100%的CPU。在任何时候只要一运行这个查询，CPU占用率就会飙升，从而导致损失。这又算是什么调优呢?

这里有另外一个例子。DBA确信在一个特定表的字段上添加索引会对某条性能不佳的SQL语句提速。所以就添加了索引。

问题是：为什么不早点构建这个索引?

难道是之前的数据库设计流程有误?如果是这样，那么DBA们可能就需要在数据建模上花费更多的时间了。

难道是新应用程序的业务逻辑太过模糊，以至于SQL无法在早期阶段获知这种情况?这便指出了应用程序设计流程上存在的问题。

鉴于SQL性能分析是一项为人所熟知的流程，那么开发人员为什么不自己进行SQL调优呢?难道他们缺乏相应工具和知识吗?

关键在于DBA必须调查造成性能不佳的根本原因，而非简单的定位单条SQL语句。否则，他们将会在以后的职业生涯里疲于应付SQL调优。对于DBA来说，将时间精力花费在SQL调优上是否值得呢?通过优化应用程序设计和数据库设计流程，让80%的索引从一开始就得以确定，这种方法岂不是更好?

有几个方法可供DBA用来做为简单SQL调优：

•添加索引;

•保持RunStats工具版本最新;

•确保数据以聚集序列进行加载和存储;

•采用良好的SQL编码实践;

•让开发人员做EXPLAIN。

•每一个方法都可以追溯到多个问题症结。