【IT168 评论】DBA往往认为SQL调优是必要的、重要的甚至是关键的。现实情况是，SQL调优所消耗的时间和资源，往往会把CPU和运行时间的节省抵消掉。

　　试问自己一个这样的问题： SQL调优出现了多久?至少25年。作为一个DBA，难道你想要花整个职业生涯在SQL语句调优上么?难道你就不想做一些比SQL调优收获更多的工作么?

　　调优需求

　　DBA通常要负责应用的性能。性能调优可分为几个类型，常见的包括：

　　•SQL调优：DBA捕获SQL语句并执行解释工具。这样便提供了格式化的访问路径信息，如此一来就可以分析是否有更好的替代方案。

　　•资源调优：DBA和系统编程人员会检测CUP，I/O以及内存等资源的消耗情况。然后分析数据库，应用程序，甚至是单条SQL语句是如何利用这些资源的，从而最小化资源使用以达到最大吞吐量。

　　•数据库子系统调优：此处，DBA和系统程序员分析数据库软件本身的资源使用情况。他们会检查配置参数，监测和跟踪数据库产生的内部统计数据。

　　其中，SQL调优是最为简单和常见的。事实上，DBA们有时将它视作最为重要的工作，而这种认知会导致错误的成就感。

　　SQL调优的目的

　　与SQL相关的最为常见的性能问题包括：一条语句执行了太长的时间，消耗了过多的资源，或是超出了某些容量限制。以下是一些例子：

　　•一条对小表进行操作的简单SQL语句持续执行了超过一个小时;

　　•一条SQL语句执行了两分钟，但在此期间消耗了两分钟的CPU时间;

　　•一条SQL语句执行失败，其出错信息为“超出CPU限制”;

　　•对在线应用程序的关键任务进行操作的SQL语句执行缓慢，从而给客户造成过度的事务处理时间。

　　资源限制水平集

　　对于SQL语句性能不佳的唯一解决之道就是“调优或升级(增加硬件资源)”，这是DBA中流传的一个常见错误观念。

　　然而，达到资源容量限制仅仅只是一个症状，并非症结所在。“调优或升级”这两种方案也仅仅是可能原因的潜在解决途径而已。

　　例如，经常有DBA通过SQL调优来降低CPU占用率。查询速度上来了，但也给了其他潜在任务一个机会去使用当前释放状态下的CPU。这也同样适用于其他的限制。这种考量方式也只是相对表征了这些症状的成因。

　　也许DBA会问，“我要怎样才能知道要进行调优的对象?”其实这是一个错误的问题。更好的问题应该是：“我们如何衡量优化?”“由谁负责企业IT的能力规划?”“对于处理新程序/SQL迁移，灾难恢复规划等类似问题，我们有没有现成的非常好的实践方案?”

　　注意，这些问题是战略的，而非战术的。它们体现的问题是DBA的优先级以及他们的时间成本。

　　原文链接：http://www.searchdatabase.com.cn/showcontent_72690.htm