多线程操作系统版本化时态表触发事务时间早于周期起始时间报错

SqlException: Data modification failed on system-versioned table because transaction time was earlier than period start time for affected records

• 触发环境：多线程模式运行Web Job时触发上述错误，作业通过调用存储过程执行数据操作
• 操作对象：存储过程包含对数据量达300万-400万条的大型时态表（temporal tables）的增、删、改逻辑
• 处理规模：单次作业运行会根据条件新增/更新4万-8万条记录
• 触发规律：单线程运行时所有操作可正常执行，并行作业数设置为2及以上时稳定抛出该错误
• 业务约束：要求最少支持3个并行线程，单线程运行方案不符合场景需求，无法采用

初步分析怀疑问题与时态表对应历史表自动生成的SysStartTime、SysEndTime列取值有关，曾参考公开方案将两个时间列的默认值设置为当前UTC时间减1秒，配置代码如下，验证后未解决问题：

DEFAULT (dateadd(second,(-1),sysutcdatetime()))

当前存在认知疑问：有资料提及时态表无法在多线程环境下正常工作，暂无法明确错误根本触发原因，也未找到多线程环境下的可行修复方案。

1. 手动修改时间列默认值的方案从机制上不生效：系统版本控制时态表的SysStartTime、SysEndTime属于系统周期列，由数据库引擎在事务提交时自动赋值，优先级高于用户自定义的DEFAULT约束，常规DML操作下引擎会直接覆盖默认值配置。
2. 多线程下报错的核心逻辑：SQL Server对时态表执行DML时，会以事务自身的启动时间作为基准做版本合法性校验。当多个并行事务操作同一条记录时，若事务A先提交更新，引擎会将该记录的SysStartTime更新为A的提交时间；此时若并行的事务B启动时间早于A的提交时间，且B尝试修改同一条记录，就会触发上述校验错误。
3. “时态表无法在多线程环境下正常工作”是错误结论：时态表原生支持多线程并发操作，报错本质是并行作业存在同一条记录的操作重叠，命中了时态表的版本顺序校验规则，而非多线程本身存在兼容性问题。

• 方案1：并行作业做严格数据分片，从根源避免跨线程操作重叠
  给3个并行线程划定完全无交集的处理数据集，比如按主键哈希取模、按业务维度（区域、业务类型、时间区间）拆分每个线程要处理的记录范围，确保不同线程不会修改同一条记录。该方案性能损耗最小，可完全满足3并行的业务要求，是首选方案。
• 方案2：调整事务配置，让同记录的并行操作排队执行
  在存储过程的增删改语句中添加UPDLOCK, HOLDLOCK查询提示，同时开启数据库的READ COMMITTED SNAPSHOT隔离级别，让并行修改同一条记录的事务按提交顺序排队等待，避免事务时间基准错位触发校验错误。该方案不需要拆分处理数据，但高并发下会存在一定的锁等待性能损耗。
• 方案3：拆分大事务，缩短时间窗口重叠概率
  将原来单次处理4万-8万条记录的大事务拆分为每批1000-2000条的短事务，缩短单事务的执行时长，降低不同并行事务操作同一条记录的时间窗口重叠概率，可作为前两个方案的补充优化手段。

注意：不要通过手动修改系统周期列取值、临时关闭系统版本控制的方式绕开校验，会直接破坏时态表的历史版本一致性，导致审计数据失真。

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