在第 3 部分中，将会介绍调优 SQL ">工作负载的方法。本文将了解如何使用 InfoSphere® Optim Query Workload Tuner 从不同来源捕获 SQL 工作负载、收集统计数据和索引分析、比较访问计划，并执行计划锁定和计划管理。本文的目标是确保 IBM® DB2® 优化器获得它所需要的信息，从而制定出基于最佳性能的 DB2 查询决策，本文还提供了一些建议，以帮助 DB2 优化器改进访问，比如收集必要的统计数据和创建最佳索引。
在第 2 部分中，介绍了单个查询调优的方法。利用 IBM InfoSphere Optim Query Workload Tuner (IOQWT) 等查询调优工具的支持，应用程序开发人员或数据库管理员可以分析单个查询的访问路径，并收集更多统计数据，重写查询或更改数据库设计，从而提高性能。
工作负载性能调优的目的是：确保应用程序满足服务水平协议，并确保系统的最佳总拥有成本 (TCO)。本文将提供一种方法，使用 IBM InfoSphere Optim Query Workload Tuner (IOQWT) 进行工作负载调优。
工作负载调优与查询调优
单个查询调优关注特定查询的性能，而工作负载调优专注于工作负载中所有查询的性能。无论执行工作负载调优还是单个查询调优，目标都是相同的：提高性能。与单个查询调优相比，工作负载调优有许多优势：
提高所有查询的性能，可以降低 TCO 并增加满足业务服务水平要求的机会。然而，一个应用程序可能包括成千上万个查询，甚至更多，为每个查询执行单个查询调优，这是不实际的。 要确定哪些统计数据将有利于每个查询，以及有利于这些统计数据的后续收集，这可能需要花费
大量的重复工作。作为一个 DBA，一个综合的 RUNSTATS 建议是有益的，可以避免重复执行 RUNSTATS。 查询调优可以识别辅助索引或更改现有索引的需求。通过隔离方式分析查询并没有考虑到索引更改对其他查询的影响，并且可能导致产生太多索引，这会影响数据的维护和管理。 为单个查询识别和收集更多统计数据，可能会导致
改善一个查询，并对其他查询产生不平衡。“积非不能成是” 的谚语用在客户工作负载中
往往并不准确。纠正一个评估错误，可能会暴露未被分析的其他查询错误。
工作负载调优方法
尽管单个查询调优具有上述缺点，但它允许专注于改善最重要的查询的性能。从整个工作负载的角度进行分析时，并不是每一个查询都可以共享与业务相同的重视程度。
可以根据执行计数、累计耗时或 CPU 时间、平均耗时或 CPU 时间等标准，为每个查询分配不同的权重。另一种方法可能是，捕获一些最耗时的 SQL 进行调优，确保样本规模足够大，以便克服与单个查询调优关联的局限性。
无论使用何种标准，一般调优方法至少包含以下四个逻辑步骤：
确定要调优的样例工作负载。 调优工作负载。 审查建议，并应用它们。 验证和比较调优之前和调优之后的性能。
步骤 2-4 组成了一个可以迭代执行的调优周期。本文将介绍每一部分。下一节介绍使用 IOQWT 捕获和调优工作负载的一些最佳实践。