跨表同步不能靠触发器硬连，因其在源表事务中执行UPDATE会导致递归、死锁、事务膨胀及阻塞；应改用触发器写队列+独立进程消费的解耦方案。
不能用触发器直接跨表自动同步——它不是为“多表联动更新”设计的，硬写 AFTER INSERT 里嵌套 UPDATE target_table 会引发递归、死锁、事务膨胀，甚至让主业务写入卡在 Transaction context in use by another session 上。
为什么跨表同步不能靠触发器硬连？
SQL Server 触发器默认运行在源表事务上下文中，一旦你在 INSERT 触发器里再对另一张本地表执行 UPDATE，就等于把两张表的修改绑进同一个事务。这不是“同步”，是强耦合：
- 目标表加了索引或触发器？连锁阻塞，源表 INSERT 就超时
- 目标表正在被其他作业读写？容易触发死锁，错误日志里只留
Msg 1205，查不出源头 - 想同步多张表？嵌套触发器开启后，
RECURSIVE_TRIGGERS一开就失控，inserted和deleted在深层触发器里可能为空 - 字段映射稍有不一致（比如源表
datetime2→ 目标表datetime），类型隐式转换失败，整条事务回滚，但业务方只看到“插入失败”，不知道是同步逻辑拖垮的
真正可控的跨表同步：触发器只写队列，别碰目标表
把触发器降级为“事件记录员”，所有跨表动作交给独立进程处理。这是唯一能避免阻塞、支持重试、可监控的路径：
- 建一张本地
sync_queue表，字段至少含：id（自增）、source_table（如 'orders'）、operation（'I'/'U'/'D'）、pk_value（主键值，bigint 或 varchar(50)）、created_at（GETDATE()） - 触发器内只做三件事：
INSERT INTO sync_queue、填入上述字段、SET NOCOUNT ON；禁止任何JOIN、SELECT或远程调用 - 用 SQL Server Agent 轮询消费，例如每 5 秒跑一次：
SELECT TOP 100 * FROM sync_queue WHERE status = 'pending' ORDER BY created_at，处理完UPDATE sync_queue SET status = 'done' - 消费者存储过程中再按
source_table和operation分支处理，显式BEGIN TRY / CATCH，失败写入sync_error_log表并保留原记录
如果必须实时且同库，用 INSTEAD OF + 显式事务控制
仅限单条或小批量变更（@@ROWCOUNT <= 10），且目标表无自身触发器。此时用 INSTEAD OF INSERT 替代 AFTER INSERT，手动拆解逻辑：
- 先
INSERT INTO target_table，捕获@@ROWCOUNT和SCOPE_IDENTITY()（如有） - 再
INSERT INTO source_table，确保主键/时间戳等关键字段已知 - 整个块包在
BEGIN TRANSACTION→COMMIT/ROLLBACK中，失败时两张表都干净 - 注意：
INSTEAD OF不会触发目标表的AFTER触发器，若目标表依赖自身触发器做审计，得额外补逻辑
最容易被忽略的坑：字段映射和 NULL 处理
哪怕只是同库两张表，字段名相同也不代表能直传。以下情况必须显式处理：
- 目标表某列为
NOT NULL，但源表对应字段允许NULL—— 触发器里得写ISNULL(inserted.col, 'default')，否则插入直接报错 - 目标表有
CHECK约束（如price > 0），源表没校验 —— 必须在触发器里加WHERE inserted.price > 0过滤，否则整批失败 - 目标表主键是
IDENTITY，但你要同步带值的主键 —— 得在消费者或INSTEAD OF里临时SET IDENTITY_INSERT target_table ON -
datetime字段从源表传过来，目标表是datetime2(3)—— 不写CONVERT(datetime2(3), inserted.created_at)，SQL Server 可能截断毫秒位，且不报错
