嘿，这个问题我在处理大型DB2表时碰到过好几次，给你详细拆解下：

1. DB2会自动重建这些索引吗？ #

答案是不会。SQL1279W只是个警告，说明REORG操作因为某些原因（比如内存不足、临时空间不够、超时）跳过了部分索引的重建。DB2不会在后台自动补做这些索引的重建工作，得你手动处理才行。

这里要注意：哪怕你用的是REORG TABLE ... INDEXES ALL命令还是触发了这个警告，那肯定是有索引没重建完成，别指望系统自己搞定。

2. 怎么查询索引重建的时长？ #

有几种实用的方法：

• 查看历史重建记录：用系统视图SYSIBMADM.INDEX_REORG_HISTORY，它会记录所有索引重建的时间线。比如这条SQL可以帮你算出每次重建的耗时：

SELECT 
  INDSCHEMA AS 索引模式,
  INDNAME AS 索引名,
  START_TIME AS 开始时间,
  END_TIME AS 结束时间,
  TIMESTAMPDIFF(2, CHAR(END_TIME - START_TIME)) AS 耗时_分钟
FROM SYSIBMADM.INDEX_REORG_HISTORY
WHERE TABSCHEMA = '你的表模式' AND TABNAME = '你的表名';

TIMESTAMPDIFF的第一个参数可以调整：1代表秒，2代表分钟，4代表小时，按需修改即可。

• 预估未来重建时长：先评估索引的碎片化程度，执行db2 reorgchk update statistics on table 模式.表名，结果里的INDEX部分会显示索引的碎片化率，数值越高通常重建耗时越久。另外用db2pd -d 你的数据库名 -indexes可以查看索引的叶节点利用率，也能辅助预估。

• 监控正在进行的重建：如果索引重建正在运行，执行db2 list utilities show detail，里面会显示已用时间和预估剩余时间，实时掌握进度。

3. 解决SQL1279W的实用思路 #

针对这个警告，我通常会从这几个方向入手：

• 手动补建未完成的索引：先找出哪些索引没重建。可以查询SYSCAT.INDEXES的REORG_REQUIRED列（值为'Y'说明需要重建），或者用db2 reorgchk的结果确认。然后对这些索引单独执行：

REORG INDEX 索引名 ON 模式.表名;

如果是多个索引，也可以批量处理。

• 给REORG分配更多资源：很多时候是资源不足导致的。可以调大SORTHEAP（排序堆大小）、SORTHEAP_THRESHOLD（DB2 10.5+版本的参数），或者在REORG命令里指定一个空间充足的临时表空间：

REORG TABLE 模式.表名 INDEXES ALL USE 临时表空间名;

这样能避免因为临时空间不足跳过索引。

• 分阶段执行REORG：超大型表别一次性处理所有索引。先执行REORG TABLE 模式.表名 INDEXES NONE整理表数据，然后再逐个重建索引，这样单次操作的资源压力小很多，不容易触发警告。

• 调整超时设置：如果是超时导致的，要么修改数据库配置参数REORG_TIMEOUT（调大超时时间），要么用ALLOW WRITE ACCESS参数做在线REORG：

REORG TABLE 模式.表名 INDEXES ALL ALLOW WRITE ACCESS;

在线REORG可以在后台持续运行，不容易因为超时中断。

• 清理冗余索引：检查下那些很少用到的索引，直接删掉。少了冗余索引，REORG的工作量会减少，后续的维护也更轻松。

内容的提问来源于stack exchange，提问作者Panadol Chong