在DB2数据库的长期运行过程中，表对象会因为持续的数据插入、更新与删除操作而逐渐产生物理存储层面的碎片。当一条记录被更新导致其长度变大而无法容纳于原页时，DB2会将其迁移至其他页并在原位置留下指向新位置的指针，这种现象称为行迁移；同时删除操作留下的空槽位会让数据页的填充率下降。reorg table命令的作用正是以全新的物理顺序重写表数据，消除迁移行、压缩空闲空间，并可依据指定的索引重新聚簇数据行，从而使后续的顺序扫描与索引查找都能以更少的I/O完成。
reorg table的底层工作机制与执行分类
从存储引擎视角看，DB2的表重组本质上是为原表创建一个按目标顺序写入的新数据镜像，再在提交点原子替换旧对象。经典离线重组（classic reorg）会以独占方式锁定表，禁止其他应用读写，它在系统临时表空间中构建排序后的数据流，然后整体回填，因此速度极快但可用性差。另一种是在线 inplace 重组，它通过渐进式地整理页内行并回收空间来避免长锁，允许查询与修改并发进行，但整个过程可能跨越数小时甚至数天，且对日志与系统资源持续占用。
选择哪一种方式取决于业务窗口与表规模。对于核心交易表若拥有夜间维护窗口，离线重组能在分钟级完成数亿行表的整理；而对于全天候服务的配置表，则只能采用 inplace 方式。无论哪种，重组前都应检查表空间高水位与剩余页数，经典重组还需要足够的临时空间存放排序中间结果，否则作业会直接失败并返回空间不足错误。
以下示例展示了一次经典离线重组并指定按主键索引聚簇的语法，以及查看进度的常用管理视图查询：
-- 离线重组表，按索引 pk_idx 聚簇
REORG TABLE schema1.orders INDEX schema1.pk_idx;
-- 在线渐进重组，允许并发
REORG TABLE schema1.orders INPLACE ALLOW WRITE ACCESS;
-- 查询重组进度
SELECT SUBSTR(TABNAME,1,20) AS tname,
REORG_STATUS,
REORG_PHASE,
REORG_MAX_PROGRESS
FROM SYSIBMADM.SNAPTAB_REORG
WHERE TABSCHEMA = 'SCHEMA1';
重组前后的配套操作与统计信息维护
很多性能问题并不是重组本身无效，而是遗漏了紧随其后的统计信息收集。DB2优化器依赖编目中的基数、列分布与页密度来生成执行计划，reorg 虽然改变了物理布局，却不会自动更新这些元数据。如果在重组后不运行 runstats，优化器仍可能基于过时的高水位与行数估计而选择全表扫描而非索引扫描，令重组收益被完全抵消。
推荐的实践是在重组提交后立即执行带有分布采样的统计命令，并对关键列收集直方图。对于分区表，还应针对发生数据变动的分区做定向统计，避免全局扫描带来的开销。此外，若表上定义了多维聚类（MDC）或插入时间聚类（ITC），重组策略会有所不同，这类表通常依靠块级回收而非行级重排，需要结合相应的 reorg 选项使用。
下面给出一组典型的维护脚本，先重组再收集统计，最后通过解释工具验证访问路径是否改善：
-- 第一步：重组 REORG TABLE schema1.orders; -- 第二步：收集统计信息，包含分布与详细索引统计 RUNSTATS ON TABLE schema1.orders WITH DISTRIBUTION AND DETAILED INDEXES ALL; -- 第三步：抓取一个慢查询的执行计划做对比 EXPLAIN PLAN FOR SELECT * FROM schema1.orders WHERE cust_id = 12345 AND order_date >= '2023-01-01';
常见误区、风险点与监控建议
一个广泛存在的误解是认为重组频率越高越好。事实上，每次重组都会消耗大量I/O与CPU，并可能在经典模式下阻塞业务，若表数据变化量极小，盲目每周重组反而拖累整体系统吞吐。更合理的做法是监控行迁移率、空页比例与平均页填充率，仅当碎片指标突破阈值（例如迁移行占比超过百分之五）才安排作业。DB2自带的 REORGCHK 命令可基于公式给出需要重组的表清单，应将其纳入定期巡检。
另一个风险点来自大表在线重组的中断恢复。inplace 重组若被异常终止，表会处于重组挂起状态，虽仍可访问但空间未完全回收，此时需再次发起原地继续或回退操作。运维侧应当为长重组配置超时告警，并在变更窗口预留重做时间。同时，在 HADR 或纯复制环境中，重组产生的日志量可能放大备机应用延迟，需要评估网络与备机写能力。
为直观对比两类重组的差异，可参考以下简表：
| 维度 | 离线经典重组 | 在线 inplace 重组 |
|---|---|---|
| 表锁定 | 独占锁，阻塞读写 | 可配置读写并发 |
| 速度 | 快，分钟级 | 慢，小时级 |
| 空间需求 | 需临时表空间 | 原表空间内渐进回收 |
| 适用场景 | 维护窗口充裕 | 持续业务不可停 |
通过合理选择重组模式、配套统计收集以及基于指标的触发机制，DB2表的物理存储质量能够稳定保持，从而让查询优化器始终拥有准确的成本模型，保障核心业务SQL在低延迟区间内运行。
DB2reorg_tabletable_reorganization修改时间：2026-08-17 18:10:31