触发器未触发的首要原因是被禁用或未匹配事件，需依次检查is_disabled状态、实际数据变更、错误日志及not for replication等隐式配置，而非直接怀疑逻辑错误。
触发器没被触发，大概率它压根没被调用，而不是逻辑写错了。先确认它是否启用、事件是否匹配、数据是否真被修改——别信“语句执行成功”这个假象。
查 sys.triggers 确认 is_disabled = 0
SQL Server 不会提示“触发器已禁用”，它就安静地挂在那里。你执行 UPDATE 成功，@@rowcount 正常，但触发器代码一丁点都没跑。
- 运行
SELECT name, is_disabled, type_desc FROM sys.triggers WHERE parent_id = OBJECT_ID('your_table_name'); - 若
is_disabled = 1，说明触发器被禁用了，哪怕它是刚建的——某些管理工具或ALTER TABLE ... DISABLE TRIGGER操作可能悄悄干了这事 - 启用命令是：
ENABLE TRIGGER your_trigger_name ON your_table_name; - 注意：跨数据库时，
sys.triggers默认只查当前库，得显式加USE [db_name];
确认 DML 操作确实影响了行
触发器只在真正变更数据时才激活。如果 WHERE 条件没命中，或更新字段值和原值完全一致（比如 SET status = status），触发器根本不会执行。
- 执行完
UPDATE后立刻查SELECT @@rowcount;—— 若返回0，说明没改到任何行，触发器自然不跑 - 检查业务逻辑：应用层是否传了空
WHERE、ID 传错、或前端把旧值又原样提交了 -
TRUNCATE TABLE是 DDL 操作，不走任何 DML 触发器，这是设计限制，不是 bug
看错误日志和 SHOW WARNINGS（需手动捕获）
触发器内出错，SQL Server 默认不抛给客户端，而是让主语句失败或静默中断。你以为“没执行”，其实是崩在半路，输出被吞了。
- 在触发器里加
TRY...CATCH块，并用RAISERROR或插入日志表记录异常：INSERT INTO trigger_debug_log (msg, time) VALUES (ERROR_MESSAGE(), GETDATE()); - 客户端执行前确保开启消息输出：
SET NOCOUNT OFF;，否则PRINT会被屏蔽 - 查 SQL Server 错误日志（
SQLServerLog或 Windows 事件查看器 → 应用程序日志），关键词搜trigger+ 表名 - 如果用 SSIS 或 ORM 执行，它们可能默认忽略触发器报错，得打开日志详细级别
留意 NOT FOR REPLICATION 和嵌套触发器设置
这两个配置项会让触发器在特定上下文中直接跳过，且不报错、不警告。
- 查触发器定义：
SELECT name, is_not_for_replication FROM sys.triggers WHERE name = 'your_trigger_name';。若为1，则在复制环境中不会触发 - 嵌套触发器被关掉（
sp_configure 'nested triggers', 0）时，AFTER 触发器中再发 DML 就不会激活下一层触发器——但上层仍会执行 - 触发器作用的表名是否带了 schema？比如写了
ON dbo.TableA却用INSERT INTO TableA（没指定 schema），某些兼容模式下可能不匹配
最常被忽略的是：你以为 UPDATE 成功了，其实它什么都没改；你以为触发器在跑，其实它被禁用或被复制配置绕过了。排查顺序一定是「状态 → 行影响 → 错误捕获 → 隐式配置」，而不是一上来就翻触发器代码。
