触发器执行失败最危险的是静默失败——不报错但数据异常，需优先检查是否启用（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 的残影。
