在DB2里想改执行计划，有哪些方法能试试和注意点

最重要的一点是，修改执行计划的根本目的通常是为了解决性能问题，比如某个SQL语句跑得特别慢，消耗了过多的系统资源，在动手之前，你必须清楚地知道，没有一种方法是“万能药”，任何改动都可能带来意想不到的影响，最首要的注意点是：永远不要在重要的生产环境上直接进行测试，你应该在一个能够还原的测试环境中进行尝试，并且每次只改变一个变量,这样才能准确评估每种方法的效果。

根据IBM官方文档和一些资深数据库管理员的经验,可以尝试的方法和对应的注意点大致可以分为以下几类：

第一类：不直接修改SQL语句，而是通过调整数据库的“环境”来影响优化器的选择。

这种方法的好处是，有时候你无法修改应用程序的源代码（比如是第三方软件），或者SQL语句本身已经非常复杂,难以动刀。

1. 更新统计信息

   • 方法：DB2的优化器就像一个聪明的导航系统，它依赖地图（也就是统计信息）来规划最快路径，如果地图过期了（比如表的数据量从1万行变成了1000万行，或者某些字段的值分布发生了巨大变化），导航自然会出错，最基础也是最有效的方法就是使用 RUNSTATS 命令来重新收集相关表的统计信息，你可以收集整个数据库的,也可以只针对某个特定的表或索引。
   • 注意点：收集统计信息本身也会消耗系统资源，所以需要在业务低峰期进行，不是收集得越频繁、越全面就越好，你需要根据数据变化的速度来制定策略，过于详细的统计信息反而会让优化器“想太多”，导致编译时间变长，IBM建议在数据发生重大变化后（如大量增删改）运行RUNSTATS。

2. 调整数据库配置参数（DB CFG）和注册表变量

   • 方法：DB2有很多“隐藏开关”可以影响优化器的行为。DFT_QUERYOPT 这个参数可以设置整个数据库的默认优化级别（从0到9），级别越高，优化器会花更多时间去寻找一个“最优”计划，但这不一定总是最快的，有时级别5比级别9更合适，还有一些更细粒度的注册表变量，DB2_OPTIMIZER_PERCENTILE 可以影响优化器是基于平均情况还是最坏情况来估算成本。
   • 注意点：这是非常危险的操作！ 随意改动这些参数可能会影响整个数据库实例下所有应用的表现，在修改前，必须记录下修改前的原始值，修改任何一个参数，都需要充分理解其含义，并在测试环境进行严格的验证,绝对不要根据网上的只言片语就盲目修改生产环境。

第二类：为特定的SQL语句提供“强制指南”或“固定路线图”。

当你确信优化器选择的计划不好，并且通过更新统计信息等方法也无法纠正时,可以考虑这类更直接的方法。

1. 使用优化概要（Optimization Profile）

   • 方法：这就像是给优化器一张“小纸条”，告诉它在处理某条特定SQL时应该怎么做，你可以通过XML文件来指定希望使用的索引、连接方法或连接顺序等,DB2会在优化该SQL时优先采纳概要中的提示。
   • 注意点：这个方法需要你对执行计划有很深的理解，能准确指出问题所在，一旦底层数据分布再次发生巨大变化，你之前写的这个“小纸条”可能就会过时，甚至变成性能瓶颈,所以需要定期回顾和验证。

2. 使用语句集中器（Statement Concentrator）

   • 方法：这主要针对的是短小、频繁执行的动态SQL，DB2可以将参数不同但结构完全相同的SQL语句“集中”起来，共用同一个执行计划，以减少编译开销,你可以通过配置参数来启用或禁用这个功能。
   • 注意点：这个方法不是去“改变”一个坏的计划，而是减少重复优化的成本，但它也可能带来副作用，比如对于参数值差异巨大的SQL，共用一个计划可能不是最优的,需要监控集中后的计划是否对大多数情况都适用。

3. 使用重优化提示（REOPT Hint）

   • 方法：在SQL语句中嵌入一个特殊的提示（Hint），REOPT ONCE 或 REOPT ALWAYS，这相当于告诉DB2：“每次执行这条语句时（或者当参数值变化很大时），别用缓存里的旧计划了，重新帮我规划一下路线吧。”这在处理参数敏感型的SQL时特别有用。
   • 注意点：使用重优化意味着每次执行都可能需要额外的编译时间，所以它是以牺牲少量编译时间为代价，来换取更准确的运行时性能，这对于执行时间很长的SQL是值得的,但对于毫秒级的短小SQL可能得不偿失。

第三类：最后的“杀手锏”，直接固定执行计划。

1. 使用计划稳定性（Plan Stability）
   • 方法：当你通过反复测试，终于找到了一个完美的执行计划后，你可以使用EXPLAIN工具将这个计划捕获出来，然后将其“固定”或“封存”起来，之后，无论数据库环境如何变化（只要表结构没变）,DB2都会强制使用这个被封存的计划。
   • 注意点：这是一个非常强大的功能，但也是双刃剑，它完全剥夺了优化器根据数据变化自我调整的能力，如果将来表的数据量暴涨，或者新增了更有效的索引，这个被固定的计划可能会迅速变得极其低效，它通常被视为解决棘手性能问题的最后手段,并且需要严格的监控和定期的重新评估。

总结性的核心注意点：

• 诊断先行：在尝试任何方法之前，必须使用DB2的解释工具（如db2exfmt）捕获当前的执行计划，准确分析瓶颈在哪里（是全表扫描慢了？是连接方式不对？还是排序开销大？）,没有诊断的优化是盲目的。
• 测试为王：所有更改必须在非生产环境验证其有效性和稳定性。
• 循序渐进：一次只尝试一种方法，并观察效果，如果混合多种改动,出了问题你无法定位原因。
• 监控与回顾：即使某种方法在当下生效了，也要建立监控机制，因为数据是活的，今天的好计划可能是明天的性能灾难，要定期回顾这些“人工干预”是否仍然有效。

修改DB2的执行计划是一个需要谨慎、细致和深厚经验的技术活动，优先选择对系统影响小、可逆性强的方法（如更新统计信息），逐步过渡到更激进的手段，核心思想是引导和帮助优化器做出正确选择,而不是完全取代它。