SQL Server触发器同步业务表需满足结构兼容、主键明确、事务可控三大前提；必须显式映射字段、区分inserted/deleted集合、禁用递归、慎用链接服务器并监控性能。
SQL Server 触发器能同步两个业务表，但必须满足几个硬性前提：结构兼容、主键明确、事务可控。直接套用网上“INSERT INTO target SELECT * FROM inserted”这类代码，90% 会出错——不是丢数据，就是死锁或触发器递归。
触发器里怎么处理字段名不一致的业务表
真实业务中，source_table 和 target_table 字段名几乎从不完全一致（比如 user_name ↔ full_name，created_at ↔ reg_time）。硬写 SELECT * 会报列名不匹配或类型转换失败。
- 必须显式列出映射关系：
INSERT INTO target_table (full_name, reg_time) SELECT user_name, created_at FROM inserted - 如果目标字段有默认值或允许 NULL，而源字段非空，需加
ISNULL()或CASE处理，否则插入失败 - 日期/数值类型要对齐：
CONVERT(DATETIME, inserted.created_at)比直接赋值更安全 - 避免用
SELECT TOP 1+ 变量赋值（如旧博客里@name = name FROM student_01 ORDER BY id DESC），这只能同步单行，批量 INSERT 时漏数据
AFTER INSERT/UPDATE/DELETE 触发器必须区分 inserted/deleted 表
很多人把 inserted 和 deleted 当成单行变量用，结果 UPDATE 时只更新了第一条，DELETE 时删错了行。SQL Server 的触发器是**集合操作**，这两张逻辑表始终是结果集。
-
INSERT：只填充inserted，deleted为空 -
DELETE：只填充deleted，inserted为空 -
UPDATE：两张表都非空，deleted是旧值，inserted是新值 - 错误写法：
UPDATE target SET col = inserted.col FROM target JOIN inserted ON ...—— 缺少JOIN deleted条件会导致 UPDATE 范围失控 - 正确做法：UPDATE 同步必须基于主键关联，且用
INNER JOIN inserted ON target.id = inserted.id，不能漏WHERE限定
跨库或跨服务器同步时链接服务器配置容易失败
用 LinkName.DB.dbo.Table 写法前，先确认链接服务器是否真通。很多问题不是触发器写错，而是底层连不上。
- 测试命令必须用完整四部分命名：
SELECT TOP 1 * FROM LinkName.[YourDB].[dbo].[target_table]，只写LinkName..dbo.target_table会报对象不存在 - 链接服务器登录映射要用
sp_addlinkedsrvlogin显式绑定账号，不能依赖@useself = 'True'（本地 Windows 身份在远程无效） - 目标库若启用了
TRUSTWORTHY ON，仅限内部可信环境；生产库建议用证书签名或最小权限账号，而非sa - 触发器内调用链接服务器时，
SET XACT_ABORT ON必须加上，否则远程失败会导致本地事务卡住
触发器同步最常被忽略的性能与循环风险
同步逻辑本身不慢，但没控制好就会引发雪崩：一个 INSERT 触发同步，目标表上也有同样触发器，又反向触发源表……最终栈溢出或死锁。
- 务必在触发器开头加
IF TRIGGER_NESTLEVEL() > 1 RETURN，禁止递归 - 大批量导入（如 SSIS 或 BULK INSERT）时，触发器逐行执行极慢，应临时禁用：
DISABLE TRIGGER trg_sync ON source_table - 不要在触发器里调用 CLR 或外部程序（如 C# 存储过程），网络延迟 + 连接池耗尽会让整个写入阻塞
- 监控
sys.dm_exec_trigger_stats，看平均执行时间是否超过 50ms——超了就得重构为定时作业或 CDC
触发器同步不是“写完就完事”，它把业务逻辑和数据变更耦合在一起。字段映射错一行、没处理 NULL、忘了关递归，轻则数据不一致，重则整库写入挂起。上线前至少用 1000 行批量 INSERT/UPDATE/DELETE 测一遍，别信单条测试。
