生产环境无停机将普通大表转换为 temporal table 相关问题咨询

以下回答基于SQL Server原生时态表特性，其他数据库的时态表实现逻辑可能存在差异。

是否会触发锁表 #

• 默认操作会触发排他的架构修改锁（Sch-M锁），锁持有期间所有对该表的读写请求都会被阻塞。该操作需要修改表结构新增两个系统时间段列、关联历史表，默认需要完全排他的表访问权限。

预计操作耗时 #

• 纯结构修改本身耗时极短，数百万行无大字段的表通常仅需要数秒到数分钟即可完成，不需要重写现有存量数据。
• 实际总耗时可能远高于结构修改时间，主要消耗在等待锁释放环节：如果操作时有长时间运行的未提交事务正在访问该表，修改操作会一直排队等待获取Sch-M锁，等待时间不可控。
• 最终耗时和表总数据量、服务器IO/CPU性能、当前业务负载均有直接关联。

是否支持ONLINE参数避免锁表 #

• SQL Server 2016及以上版本支持ONLINE = ON参数用于时态表启用的结构修改阶段，可以避免长时间锁表，语法参考：

-- 第一步：添加时间段列、定义系统时间周期，开启ONLINE模式
ALTER TABLE 你的业务表名
ADD 
    SysStartTime DATETIME2(7) GENERATED ALWAYS AS ROW START HIDDEN CONSTRAINT DF_表名_SysStartTime DEFAULT SYSUTCDATETIME(),
    SysEndTime DATETIME2(7) GENERATED ALWAYS AS ROW END HIDDEN CONSTRAINT DF_表名_SysEndTime DEFAULT CONVERT(DATETIME2(7), '9999-12-31 23:59:59.9999999'),
PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime)
WITH (ONLINE = ON);

-- 第二步：开启系统版本控制，关联历史表
ALTER TABLE 你的业务表名
SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.你的业务表名_History));

• ONLINE = ON生效期间，业务对表的读写操作可以正常执行，仅在操作最终提交阶段会申请极短时间的Sch-M锁，对业务几乎无感知。
• 如果使用的数据库版本不支持ONLINE = ON参数，建议在业务低峰期执行操作，操作前先查询是否有长事务占用该表，避免出现长时间业务阻塞。

内容的提问来源于stack exchange，提问作者Alessio Innocenzi