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。
• 每一个方法都可以追溯到多个问题症结。

    如何减少CUP使用

    如果症状表现为大量的CPU资源请求，那么原因是什么？在SQL语句层面可能包括：

• 糟糕的SQL代码；
• 糟糕的应用程序代码；
• 交易应用的提交策略不佳；
• 过度使用批量卸载/加载/备份流程；
• 频繁使用RunStats；
• 对缓冲池大小的选择不当；
• 对BP页集选择的不当分配；
• 排序池/RID池的内存分配不足；
• 内存管理不当导致实际存储的分页；
• 对DB2子系统的配置不当；
• DB2配置为最大I/O吞吐量，而非最小CPU利用率；
• DB2配置为高性能写访问；
• 频繁执行备份；
• 执行LOAD ... LOG YES。

　　进行SQL语句调优将解决CPU容量问题，在正确得出类似结论之前，DBA必须首先收集相关数据。甚至还需要做更多的工作来证明通过给DB2子系统添加CPU容量可以增加吞吐量。

　　我并不是说SQL调优总是在浪费时间，如果你不衡量在这一过程中资源耗费和节省的状况，你又怎么能知道这样做值不值得呢？作为一个管理者，我更倾向于DBA能将它们宝贵的时间投入到灾难恢复准备，数据可用性和安全性等这些高优先级的问题中去。

　　开发人员编写性能不佳的SQL代码

　　这可以说是一个普遍的事实存在。DBA可以给开发人员提供最佳实践以及SQL实现标准，让他们知道好的SQL开发人员应该怎样写代码，然后提供SQL代码示例。

　　另一个常被忽视的问题是： IT部门有对用户的资源成本负责吗？也就是说，他们有对CPU和磁盘存储的使用进行支付吗？对于事务/应用程序有没有订立服务水平协议以及配套的处罚措施呢？如果不存在任何的这样的机制，那么程序开发人员就会没有动力去编写性能优良的代码。

　　那么我到底要不要做SQL调优？

　　要摆脱疲于应付SQL调优的状态就要做根本原因分析。为什么不良SQL总是不断汹涌而来？难道是开发人员写代码太糟糕？如果是这样，也许解决之道就是培训，或是让他们自己进行调优。工具是否会自动生成性能不佳的SQL呢？答案可能会比较复杂，因为它会涉及到工具的升级，索引管理，RunStats管理，甚至是DB2子系统调优等诸多方面。

　　最后，DB2子系统，数据共享以及操作系统配置是最常影响应用程序和SQL性能的。如果你花费大量时间在SQL查询调优上，也仅仅是发现系统参数值造成这样的结果，难道你不会觉得烦躁吗？难道你就真的希望每每配置发生改变就要一遍又一遍的对单条不良SQL语句进行调优吗？

　　总结

　　如果DBA花费时间去做SQL调优而不是修复导致问题的根本原因，那么支持人员和IT部门要如何成长？你又如何才能有机会变得积极主动呢？企业则会越来越依赖于各种问题专家。

　　如果你花费职业生涯来做SQL调优，你可能会成为这方面的专家。这意味着类似子系统配置，新功能实施，协调灾难恢复等工作就会被交给其他人去做。这对于DBA职业的发展其实是很不利的。