想象这样一个场景：财务部门突然要求你查出某个客户账户在三个月前某一天的确切余额，而这张表的记录已经被修改过几十次。如果没有历史数据留存，你几乎无从下手。DB2的时间旅行查询Time Travel Query正是为解决这类问题而生的，它基于时态表temporal table机制，让你可以用一条普通的SELECT语句回溯数据在任意历史时刻的状态，就像坐上了时光机。
时间旅行查询的核心原理：时态表机制
DB2的时间旅行查询并不是什么魔法，它的底层依赖的是时态表。简单来说，一张时态表由两部分组成：基础表存储当前有效数据，历史表存储所有被修改或删除的旧版本记录。当执行UPDATE或DELETE操作时，DB2不会直接丢弃旧数据，而是自动把旧版本行搬移到历史表中，并记录其有效区间的起止时间。
具体来说，DB2支持两种时态语义。第一种是系统时间system time，由数据库自动维护，记录的是某行数据在数据库中的生效区间，UPDATE、DELETE语句都会自动更新这个区间。第二种是应用时间application time，也叫业务时间business time，由应用程序显式维护，例如保险单的保障期、合同的生效期等。两种时间可以单独使用，也可以组合成双时态表bitemporal table，同时回答“数据库里这行数据什么时候存在过”和“业务上这条记录在什么时间段有效”两个维度的问题。
这种机制的优势在于完全由数据库内核保证一致性，不需要开发人员手工写触发器把旧数据插入历史表，也不用担心应用程序漏记变更。事务提交时系统时间戳由DB2自动生成，基于事务开始时刻，且单调递增，保证了同一次事务内修改的数据具有一致的时间边界。
如何创建时态表并启用时间旅行
要让一张表支持时间旅行查询，首先需要把它定义为系统时间时态表。关键点有三个：定义两个时间戳列作为区间起止、创建关联的历史表、通过ALTER TABLE把两者绑定起来。下面是完整的建表语句示例。
-- 创建基础表，包含系统时间区间列
CREATE TABLE orders (
order_id INTEGER NOT NULL,
customer_id INTEGER NOT NULL,
amount DECIMAL(12,2),
sys_begin TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN,
sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID,
trans_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID,
PERIOD SYSTEM_TIME (sys_begin, sys_end),
PRIMARY KEY (order_id, sys_begin)
);
-- 创建同结构的历史表
CREATE TABLE orders_hist LIKE orders;
-- 将历史表绑定为基础表的历史部分
ALTER TABLE orders ADD VERSIONING USE HISTORY TABLE orders_hist;几个细节值得注意。首先，sys_begin和sys_end使用TIMESTAMP(12)精度，即纳秒级别，这是为了在同一事务内区分先后操作。其次，PERIOD SYSTEM_TIME子句声明了系统时间区间，主键必须把sys_begin包含进来，因为同一业务主键在历史中会存在多个版本。最后，ADD VERSIONING语句执行后，历史表就完全交给DB2管理了，你不能直接对历史表做INSERT、UPDATE、DELETE，否则会报SQL0803之类的约束错误。
绑定完成后，后续所有针对orders表的更新和删除操作都会自动留痕。比如执行UPDATE orders SET amount = 500 WHERE order_id = 1，旧版本的行会带着原来的sys_begin和新的结束时间被写入orders_hist，整个过程对应用完全透明。
FOR SYSTEM_TIME AS OF：回溯查询的四种姿势
时态表建好之后，时间旅行查询的语法非常直观，核心是在表名后面加上FOR SYSTEM_TIME AS OF等子句。DB2提供了四种查询模式，覆盖了几乎所有历史追溯场景。
-- 1. 查询某个历史时刻的数据快照
SELECT * FROM orders
FOR SYSTEM_TIME AS OF '2024-06-01-00.00.00'
WHERE customer_id = 1001;
-- 2. 查询一段区间内的所有版本
SELECT * FROM orders
FOR SYSTEM_TIME FROM '2024-06-01-00.00.00' TO '2024-07-01-00.00.00';
-- 3. 查询区间内所有版本，包含区间边界上的版本
SELECT * FROM orders
FOR SYSTEM_TIME BETWEEN '2024-06-01-00.00.00' AND '2024-07-01-00.00.00';
-- 4. 当前数据与全部历史数据一起查
SELECT * FROM orders FOR SYSTEM_TIME ALL;AS OF是最常用的形式，它返回的是指定时刻的表快照，查询结果中不包含时间列，就像直接查询当时的表一样。FROM TO和BETWEEN则用于审计场景，能看到一行数据在区间内经历了哪些版本变化。FOR SYSTEM_TIME ALL会把基础表和所有历史版本合并返回，常用于全量数据导出或问题排查。
有一点容易被忽视：如果不写FOR SYSTEM_TIME子句，查询默认只访问当前数据，行为与普通表完全一致，已有应用的SELECT语句不需要任何改动。这种向后兼容的设计使得在存量系统上启用时态表的风险非常低，可以逐表灰度推进。
系统时间与应用时间的区别及典型场景
很多初学者会把系统时间和应用时间混为一谈，实际上两者语义完全不同。系统时间回答的是“数据库什么时候知道这件事”，而应用时间回答的是“这件事在业务上什么时候成立”。举个典型例子：7月1日销售员补录了一笔6月1日的订单，系统时间是7月1日（录入时刻），应用时间是6月1日（业务发生时刻）。
如果需要按业务时间追溯，建表时改用PERIOD BUSINESS_TIME声明业务区间列，查询时使用FOR BUSINESS_TIME AS OF ...子句。保险、金融行业的费率表、利率表通常采用业务时间建模，因为一条费率记录可能“在未来生效”或“追溯生效”，这是系统时间无法表达的。两种时间组合的双时态表则能回答“在某个历史时刻，系统认为某业务时间点的有效数据是什么”这类复杂问题，这正是监管审计中最常见的需求。
在实际落地时还有几个建议：历史表会持续增长，应结合数据保留策略定期用ALTER TABLE ... ALTER PERIOD ... END截断过老的历史区间；时态表上的UPDATE代价高于普通表，高频更新场景要评估历史表膨胀速度；查询历史数据时尽量带上时间条件以外的过滤条件，让DB2能利用索引裁剪扫描范围。掌握这些要点后，时间旅行查询会成为你手中处理数据追溯问题最省力的工具。
DB2时间旅行查询Time Travel QueryDB2 temporal table修改时间：2026-09-16 20:18:50