DB2的查询优化器在生成执行计划时，并不是凭直觉做选择，而是靠一套数学化的成本模型来估算每种候选计划的执行代价，然后挑选总成本最低的那个方案。这套成本估算机制在DB2内部通常与opt_cost_model（优化成本模型）密切相关，理解它的工作方式，对排查SQL性能问题、调整数据库配置乃至改写SQL都有直接帮助。
成本模型的基本构成：CPU、I/O与通信代价
DB2优化器估算的成本主要由三个部分组成：CPU成本、I/O成本和网络通信代价。CPU成本对应处理数据行所需的指令开销，包括谓词求值、排序、哈希运算等；I/O成本对应从磁盘或缓冲池读取页面所需的代价，通常又细分为随机I/O和顺序I/O；通信代价则主要出现在DPF（数据分区特性）等分布式环境下，表示在分区之间传输数据所需的成本。
这三类成本在内部会被加权求和成一个无量纲的成本值。这个值本身没有"秒"这样的物理单位，而是一个相对量，因此Explain输出中看到的成本数字只能用来比较同一查询不同计划之间的优劣，不能直接换算成执行时间。这也解释了一个常见现象：有些计划成本很低但执行很慢，往往是统计信息失真或者成本模型的默认假设与实际数据分布不符导致的。
优化器在计算I/O成本时，会结合缓冲池命中率做出假设。默认的成本模型倾向于假设一定比例的页面可以命中缓冲池，如果实际工作负载的缓冲池命中率与假设差异很大，估算就会偏差。这也是为什么调优时常建议调整优化器级别（例如通过SHEAPTHRES、查询优化级别参数）来影响成本模型的激进度。
统计信息与过滤器因子：成本估算的输入源
成本模型的输出是否准确，几乎完全取决于输入的统计信息是否可靠。DB2通过RUNSTATS命令采集表和索引的统计信息，包括行数、页数、列的最小值最大值、频度统计（FREQ）和分位数统计（QUANT）。优化器利用这些信息计算过滤器因子（Filter Factor，简称FF），也就是一个谓词能过滤掉多少比例的行。
-- 采集表和索引的详细统计信息 RUNSTATS ON TABLE SALES.ORDERS WITH DISTRIBUTION ON COLUMNS (CUSTOMER_ID, ORDER_DATE) AND DETAILED INDEXES ALL; -- 查看关键统计信息 SELECT TABNAME, CARD, NPAGES, FPAGES FROM SYSCAT.TABLES WHERE TABNAME = 'ORDERS';
举个例子，如果状态列有十个不同取值且分布均匀，优化器会假设STATUS = 'PAID'的过滤器因子约为0.1。但如果实际数据严重倾斜，比如90%的行状态都是PAID，而没有收集列分布统计，优化器就会严重低估返回行数，进而低估后续连接和排序的成本，选出一个看起来便宜、实际昂贵的计划。这就是典型的"统计信息失真导致计划错误"问题。
对于连接操作，过滤器因子同样关键。嵌套循环连接的成本估算高度依赖外表和内表各自过滤后的基数估算，基数估算又依赖过滤器因子，误差会在多层连接中不断放大。因此维护好统计信息，特别是对数据倾斜严重的列使用WITH DISTRIBUTION选项，是保证成本模型正常工作的第一步。
如何查看成本：借助Explain分析计划构成
理解成本模型最好的办法是实际观察一个执行计划的成本构成。DB2提供了Explain工具，可以将优化器选中的计划以及每个操作符的估算成本、估算基数输出到explain表里。常用做法是先设置CURRENT EXPLAIN MODE，执行查询后再用db2exfmt格式化输出。
-- 启用解释模式 SET CURRENT EXPLAIN MODE EXPLAIN; -- 执行目标查询（只生成计划，不真正执行） SELECT O.ORDER_ID, C.NAME FROM SALES.ORDERS O JOIN SALES.CUSTOMERS C ON O.CUSTOMER_ID = C.CUSTOMER_ID WHERE O.ORDER_DATE > '2024-01-01'; SET CURRENT EXPLAIN MODE NO; -- 格式化输出执行计划 -- db2exfmt -d SAMPLE -1 -o plan.txt
在db2exfmt的输出中，每个操作符旁边都有两个关键数字：估算成本（Total Cost）和估算返回行数（Cardinality）。排查性能问题的基本技巧，就是对比估算行数和实际行数。如果某个操作符估算返回100行，实际返回100万行，那么问题几乎一定出在统计信息或过滤器因子上，而不是数据库本身的处理能力。
此外，还可以关注成本较高的操作符类型。排序操作符（SORT）成本高通常意味着需要检查是否有索引可以消除排序；表扫描（TBSCAN）成本高说明缺少合适的索引；哈希连接（HSJOIN）成本异常则可能是内表估算基数不准。逐个分析这些高成本节点，就能定位到成本模型给出错误判断的具体环节。
影响成本模型行为的参数与调优思路
除了统计信息，一些数据库配置参数也会影响成本模型的计算。查询优化级别（query optimization level）决定了优化器可用的连接枚举技术和成本计算精度，级别越高，考虑的候选计划越多，编译时间也越长。OLTP场景通常使用默认级别即可，而复杂报表查询有时可以适当提高级别以获得更好的计划。
CPU速度相关的优化器配置（如CPUSPEED）决定了CPU成本项的权重。如果服务器硬件升级后查询计划反而变差，可以检查这些参数是否需要重新校准，或者在部分版本中使用相关存储过程让它自动测量。缓冲池大小也间接影响成本模型，因为更大的缓冲池会改变I/O成本的估算假设。
最后要提醒的是，成本模型本质上是基于统计的近似计算，它不能保证永远选出最优计划。实践中比较稳妥的做法是：保持统计信息及时更新，对关键查询定期用Explain审查计划稳定性，必要时借助优化配置文件（Optimization Profile）对个别SQL固定访问路径。把成本模型当成一个可以理解和调整的工具，而不是黑盒，SQL性能问题会变得容易定位得多。
DB2opt_cost_model成本模型修改时间：2026-09-13 22:12:52