DB2 中的 opt_enable_partial_valid_time 属于实例级注册变量，用于改变优化器对含有有效时间（application period）表在时间查询下的访问策略。没有启用该变量时，即使业务表已经定义了 BUSINESS_TIME 区间，按某个时间点或时间段检索数据，优化器仍然可能选择全表扫描或索引全扫描，因为谓词与区间列之间的等价关系没有被主动推导。启用之后，优化器会尝试把 AS OF 或 FOR BUSINESS_TIME 这种时间语义转换为针对起止列的范围条件，从而只读取部分数据分区或索引页面。
参数背景与应用前提
DB2 从较早版本开始支持 application-period temporal table，它允许在一张普通表中增加一个 PERIOD 定义，指定两个日期或时间戳列作为有效时间区间。比如保险公司保单表，每行数据都有一个 bus_start 和 bus_end，代表该保单版本在业务上生效的时间范围。创建表时可以写成 PERIOD BUSINESS_TIME (bus_start, bus_end)。这种表的主要优势是支持时间敏感的查询，如 FOR BUSINESS_TIME AS OF 表示只看在某个时间点有效的行，或者 FOR BUSINESS_TIME FROM ... TO ... 表示看某段时间内有效的行。
然而，定义有效时间并不等于优化器会自动高效执行时间查询。优化器生成访问计划时，如果没有专门的规则处理时间谓词，它只会把普通的 WHERE 条件应用到基表上，而不会根据 PERIOD 结构推导出 bus_start 与 bus_end 的范围关系。例如查询某一天的保单，理想情况下应该扫描 bus_start 小于等于该天且 bus_end 大于该天的数据，但默认计划可能扫描整表再过滤，导致大量无效行进入上层。opt_enable_partial_valid_time 正是用于启用优化器中针对这种部分有效时间条件的访问路径生成逻辑。
该变量主要影响使用 application-period temporal table 的查询，对 system-period temporal table 的事务时间查询通常有另外的注册变量和内部机制。所以在开启前需要确认表类型是否属于 application-period，并且已经针对有效时间起止列建立了合适的索引，否则优化器即使推导出范围条件，缺少索引支撑也无法显著改善性能。
如何启用 opt_enable_partial_valid_time
该参数通过 db2set 命令设置，属于实例级注册变量。设置后需要重启 DB2 实例使变量生效。具体步骤如下：
-- 在实例用户下执行 db2set DB2_OPT_ENABLE_PARTIAL_VALID_TIME=YES db2stop force db2start
上面的命令中，db2set 用于写入注册变量，db2stop force 强制停止实例，db2start 重新启动。设置完成后可以用 db2set -all 查看变量是否已经写入，确认输出中包含 DB2_OPT_ENABLE_PARTIAL_VALID_TIME=YES。如果是在多实例环境中，需要先切换到目标实例的环境变量，避免设置到错误的实例。
除了全局开启之外，还可以在会话级通过优化配置文件或语句级提示进行调整，但这个变量属于实例级的行为开关，通常在测试环境验证后再推广到生产环境。建议先在测试库上启用并重新绑定相关存储过程和包，因为执行计划会变化，绑定信息中缓存的老计划可能不会自动失效。可以用 db2rbind 或重新执行 BIND 操作来刷新包。
另外，该参数值区分大小写，官方文档中通常使用大写 YES 和 NO。如果写成 yes 或 true，部分版本可能无法识别，建议严格使用 YES 或 NO。在云数据库或 Data Studio 管理界面中，也可以找到对应注册变量进行修改，但底层仍然等价于 db2set 操作。
执行计划与查询示例
假定已有保单表结构如下：
CREATE TABLE policy (
policy_id INT NOT NULL,
coverage_amount DECIMAL(10,2),
bus_start DATE NOT NULL,
bus_end DATE NOT NULL,
PERIOD BUSINESS_TIME (bus_start, bus_end)
);
CREATE INDEX idx_policy_time ON policy (bus_start, bus_end);
在没有启用 opt_enable_partial_valid_time 之前，执行下面的查询：
SELECT * FROM policy FOR BUSINESS_TIME AS OF DATE '2024-01-15';
可以通过 db2exfmt 工具查看执行计划，很可能看到表扫描或者索引扫描的范围是整个索引，然后再通过过滤条件筛选有效时间。启用变量后，同样一条 SQL 的执行计划会发生变化，优化器可能生成包含 bus_start <= '2024-01-15' 和 bus_end > '2024-01-15' 的索引范围扫描，或者至少把这两个条件作为 access predicate 而不是 filter predicate。
判断优化是否生效，可以对比访问计划中的 Predicate Information 部分。在启用前，时间条件往往出现在过滤谓词中，过滤发生在数据页读取之后；启用后，时间条件可能出现在启动/停止键中，即索引扫描只读取符合有效时间区间的叶子节点。这种变化对于大表尤其明显，因为扫描的索引页和数据页数量会大幅下降。还可以观察查询的 I/O 统计，BILLS 指标或 Rows Retrieved 数量应显著减少。
需要注意，如果表中有效时间区间数据分布非常分散，或者查询经常跨越大部分时间区间，部分有效时间优化带来的收益会降低。更适合的场景是表数据量极大，单次查询只关心一个时间点或较短时间段，且时间区间与物理数据组织有一定相关性。周期性加载或归档策略也有助于保持索引范围扫描的高效。
常见配置误区与排查方法
第一个常见误区是把 opt_enable_partial_valid_time 和系统事务时间表混淆。系统事务时间表由 DB2 自动维护起止时间，查询语法通常使用 FOR SYSTEM_TIME AS OF。这个变量主要针对业务时间表，如果业务表没有定义 PERIOD BUSINESS_TIME，设置该变量不会产生任何效果。其次，仅开启变量但不建立复合索引，优化器可能仍然选择全表扫描，因为范围条件需要索引作为访问路径。建议对有效时间列建立 (bus_start, bus_end) 或反向顺序的复合索引，必要时使用包含列减少回表。
第二个误区是设置后没有重新绑定包。DB2 中的静态 SQL 会缓存执行计划，如果应用使用存储过程或嵌入式 SQL，设置注册变量后如果不重新绑定，旧计划可能继续使用，导致优化效果不明显。可以用 db2rbind dbname -l db2rbind.log 批量重新绑定，然后再检查 db2exfmt 输出。如果是动态 SQL，每次执行都会重新优化，设置后立即生效的可能性更高。
排查时可以先运行 db2set -all 确认变量值，再执行一个简单的 EXPLAIN 命令，例如 db2 explain plan for SELECT ...，然后使用 db2exfmt -d dbname -1 查看访问计划。如果计划中仍然看不到有效时间列的 start/stop 键，需要检查表定义是否包含 PERIOD BUSINESS_TIME，以及查询是否使用了正确的 temporal 语法，因为普通的 WHERE bus_start <= ? AND bus_end > ? 不属于该变量的优化范围，只有 FOR BUSINESS_TIME 语法才会触发时间语义分析。
最后，建议在启用后对关键查询做一次基准测试，记录 I/O 时间、CPU 时间和 buffer pool 命中率变化。如果出现部分查询性能反而下降，可能是因为新的访问计划对某些参数值不适合，或者索引相关性差。此时可以关闭变量或调整索引设计，而不必全盘否定部分有效时间优化本身。合理的做法是先在小规模数据上验证，再逐步推广到生产环境。
DB2 opt_enable_partial_valid_time部分有效时间temporal table修改时间：2026-08-22 11:01:57