触发器执行失败最危险的是静默失败——不报错但数据异常，需优先检查是否启用（mysql查status=enabled、sql server查is_disabled=0），再排查truncate跳过、update无变更跳过、错误被吞（用show errors/show warnings）、以及禁止修改自身表（error 1442）等典型场景。

触发器执行失败往往不报错，只让数据“悄悄出错”——这是最危险的情况。它不拦你操作，但审计字段为空、关联表没同步、子表残留，问题可能几天后才暴露。

触发器根本没跑？先查是否启用

触发器被禁用时，DML 语句照常成功，但逻辑完全不执行，且无任何提示。

• MySQL：运行 SELECT TRIGGER_NAME, STATUS FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'your_trigger_name';，确认 STATUS 是 ENABLED；若为 DISABLED，需重建（ALTER TRIGGER ... ENABLE 在 MySQL 5.7 不可用）
• SQL Server：运行 SELECT name, is_disabled FROM sys.triggers WHERE name = 'your_trigger_name';，is_disabled = 1 表示已停用，执行 ENABLE TRIGGER your_trigger_name ON your_table;
• SHOW TRIGGERS 只查当前数据库，跨库必须先 USE db_name

触发器跑了但没生效？重点看三类静默跳过场景

不是所有 DML 都会激活触发器，有些情况它连入口都不进。

• TRUNCATE TABLE 是 DDL 操作，不生成 INSERTED/DELETED 伪表，任何 DML 类型触发器都天然不触发
• MySQL 8.0+ 中，UPDATE t SET x = x 或 SET y = 'same_value' 这类无实际变更的语句，默认跳过触发器（SELECT @@row_count 返回 0 可佐证）
• SQL Server 中，若 UPDATE 影响行为 0 行，AFTER UPDATE 仍会触发；但 MySQL 默认不触发，除非 sql_mode 含 STRICT_TRANS_TABLES

触发器崩在半路？错误常被吞掉，得主动捞

触发器内报错往往不抛给客户端，主语句可能失败却只显示模糊提示，或直接静默中断。

• MySQL 执行 DML 后立刻运行 SHOW ERRORS LIMIT 1，比客户端错误更准；若为空，再试 SHOW WARNINGS，常能捕获 Unknown column 'xxx' 这类真实错误
• 查 MySQL 错误日志：SELECT @@global.log_error; 确认路径，然后搜 ERROR 1442、ERROR 1048 或触发器名
• SQL Server 中，PRINT 输出需客户端开启 SET NOCOUNT OFF 才可见；否则你以为没输出，其实是被屏蔽了
• 所有跨表操作前加 IF EXISTS (SELECT 1 FROM other_table WHERE ...)，避免因子查询无结果导致 SELECT INTO @var 赋 NULL，后续判断失效

触发器里改自己这张表？ERROR 1442 是硬限制

MySQL 明确禁止在触发器中修改触发它的同一张表，这不是配置问题，是引擎级限制。

• 典型报错：ERROR 1442 (HY000): Can't update table 't1' in stored function/trigger...
• 常见踩坑：BEFORE INSERT 里查本表最大 ID 再赋值；AFTER UPDATE 里又 UPDATE t1 做统计更新
• 修复方向只有三个：ON UPDATE CASCADE 外键替代、应用层分步操作（先 INSERT，再单独 UPDATE 计数表）、或改用存储过程 + 事件调度器异步处理
• 别信“只改其他行就没事”——整张表都被锁死，只要语句涉及本表，就触发限制

真正难排查的从来不是语法错误，而是那些不报错、不写日志、只让数据慢慢偏移的静默失败。每次上线新触发器，务必用空值、重复值、跨事务并发这三类边界数据实测一遍，否则线上等你的是审计对不上、报表突变、客户投诉——而错误日志里可能只有一行 SHOW WARNINGS 的残影。