DB2优化器在生成执行计划时，依赖的是表中数据的统计信息，比如表的行数、数据页数量、列值的分布情况、索引的层级深度等。如果这些信息过期或者缺失，优化器就可能做出错误的成本估算，选择低效的访问路径，比如该走索引却走了全表扫描。RUNSTATS命令是DB2收集和更新这些统计信息的主要工具，用好它是数据库性能调优的基本功。
统计信息对查询优化的作用机制
DB2的优化器是一个基于成本的优化器（CBO），它并不直接查看表里的真实数据，而是读取系统编目表（如SYSCAT.TABLES、SYSCAT.COLUMNS、SYSCAT.INDEXES）中记录的统计信息。当你提交一条SQL语句时，优化器会根据这些统计信息估算各种执行方案的成本，包括IO成本和CPU成本，最终选择成本最低的方案。
举个例子，一张订单表有5000万行数据，在ORDER_DATE列上有索引。如果统计信息是三年前收集的，当时表只有50万行，优化器会认为走全表扫描成本很低，从而放弃索引扫描，查询性能会急剧下降。反过来，如果统计信息准确，优化器能正确判断出索引扫描的代价远小于全表扫描，执行计划就会走对方向。
可以通过下面的SQL查看当前表的统计信息收集时间：
-- 查看表统计信息的最后收集时间 SELECT TABSCHEMA, TABNAME, CARD, NPAGES, STATS_TIME FROM SYSCAT.TABLES WHERE TABNAME = 'ORDER_INFO'; -- CARD 表示表行数，NPAGES 表示数据页数 -- STATS_TIME 表示统计信息的收集时间
如果发现STATS_TIME距离当前时间很久远，或者CARD值与实际行数差距巨大，就说明该重新执行RUNSTATS了。
RUNSTATS命令的基本用法与常用选项
RUNSTATS最基本的用法是对单表收集统计信息，在命令行处理器（CLP）中执行：
-- 对表收集基础统计信息
RUNSTATS ON TABLE db2inst1.order_info;
-- 对表和所有索引同时收集统计信息
RUNSTATS ON TABLE db2inst1.order_info
WITH DISTRIBUTION AND DETAILED INDEX ALL;
WITH DISTRIBUTION选项会让DB2额外收集列的数据分布信息，包括频繁出现的值和分位数信息。这对谓词条件选择性判断非常有用，特别是当列上的数据分布严重倾斜时。比如STATUS列中90%的值都是COMPLETED，如果只收集基础统计信息，优化器无法知道这种倾斜，而带分布选项的收集能让优化器精确估算WHERE条件能过滤掉多少行。
DETAILED INDEX ALL会收集所有索引的详细统计信息，包括索引的聚簇因子。聚簇因子反映了索引键值与数据页物理存储的有序程度，聚簇因子好的索引在范围扫描时能减少大量随机IO。索引相关的几个常用组合如下：
-- 只收集表的统计信息，不影响索引
RUNSTATS ON TABLE db2inst1.order_info ON KEY COLUMNS;
-- 收集表和指定索引的统计信息
RUNSTATS ON TABLE db2inst1.order_info
AND INDEX db2inst1.idx_order_date;
-- 收集表、索引列和详细索引统计信息
RUNSTATS ON TABLE db2inst1.order_info
AND DETAILED INDEX ALL;
-- 大表可以设置采样比例，减少收集耗时
RUNSTATS ON TABLE db2inst1.order_info
WITH DISTRIBUTION AND INDEX ALL
TABLESAMPLE SYSTEM(10);
TABLESAMPLE选项对于超大规模的表很实用，只采样10%的数据页面来估算统计信息，速度会快很多，精度略有损失，一般在亿级大表的例行维护中经常采用。需要注意的是，RUNSTATS执行期间会持有表上的锁，对于业务高峰期的生产库，建议放在低峰期窗口执行，或者使用ALLOW WRITE ACCESS选项允许并发读写：
-- 允许并发读写访问的情况下收集统计信息
RUNSTATS ON TABLE db2inst1.order_info
WITH DISTRIBUTION AND DETAILED INDEX ALL
ALLOW WRITE ACCESS;
批量执行与自动化维护策略
实际运维中表往往有几百上千张，逐个手写RUNSTATS语句不现实。可以借助系统存储过程ADMIN_CMD配合游标，批量生成并执行命令。下面是一段常见的SHELL脚本，用于对指定SCHEMA下的所有表执行RUNSTATS：
#!/bin/bash
# 批量收集指定模式下所有表的统计信息
db2 connect to sampledb user db2inst1 using yourpassword
db2 -x "SELECT 'RUNSTATS ON TABLE ' || RTRIM(TABSCHEMA) || '.' || RTRIM(TABNAME) ||
' WITH DISTRIBUTION AND DETAILED INDEX ALL;'
FROM SYSCAT.TABLES
WHERE TABSCHEMA = 'DB2INST1' AND TYPE = 'T'" > runstats.sql
db2 -tvf runstats.sql
db2 connect reset
除了手动触发，DB2还提供了自动统计信息收集功能。通过设置数据库配置参数AUTO_MAINT、AUTO_TBL_MAINT和AUTO_RUNSTATS，数据库会在后台自动检测统计信息是否过期并择机收集：
-- 开启自动维护和自动RUNSTATS UPDATE DB CFG FOR sampledb USING AUTO_MAINT ON; UPDATE DB CFG FOR sampledb USING AUTO_TBL_MAINT ON; UPDATE DB CFG FOR sampledb USING AUTO_RUNSTATS ON; -- 查看自动维护相关配置 GET DB CFG FOR sampledb SHOW DETAIL;
开启自动收集后，DB2会在统计信息明显过期（比如表数据变化超过一定比例）时，利用系统空闲窗口自动执行RUNSTATS。对于变化频繁的核心业务表，还可以进一步开启自动统计信息概要分析（AUTO_STMT_STATS），让优化器在语句执行层面动态校正估算偏差。
执行时机与常见注意事项
什么时候该执行RUNSTATS？一般来说有这几个关键时机：大批量数据导入或删除之后，包括LOAD、IMPORT操作完成后；新建索引之后；查询性能突然下降且执行计划发生变化时；以及数据库迁移或升级后。LOAD操作尤其要注意，LOAD完成后表的统计信息可能完全失效，必须在LOAD之后紧跟RUNSTATS，否则查询性能会明显异常。
还有几个容易踩的坑需要提醒。第一，RUNSTATS收集完统计信息后，已经缓存在包缓存中的旧执行计划不会自动更新，需要执行REBIND重新绑定静态SQL对应的包，动态SQL则会随新语句的编译自动生效：
-- 重新绑定存储过程或静态SQL包，使其使用新的统计信息 REBIND PACKAGE db2inst1.PK12345;
第二，分布统计信息的默认采样精度可以通过数据库配置调整，对于数据分布倾斜严重的列，建议适当提高 frequents值和分位数的数量，让估算更贴近真实分布。第三，临时表、MQT物化查询表也需要维护统计信息，很多人只关注普通表而忽略了MQT，导致基于MQT的查询计划不佳。
总结一下，统计信息维护是DB2性能管理中最基础也最见效的一环。建议的实践方案是：开启自动RUNSTATS处理日常小表，对核心大表在业务低峰期用采样方式例行收集，在批量ETL作业末尾固定追加RUNSTATS步骤，并养成定期检查STATS_TIME的习惯。把这套流程固化下来，绝大多数因为统计信息过期导致的性能问题都能提前避免。
DB2统计信息RUNSTATS命令数据库优化修改时间：2026-09-13 14:26:36