触发器根本没被调用，首要原因是被禁用：mysql需查information_schema.triggers中status是否为enabled，sql server需查sys.triggers中is_disabled是否为0；其次update无实际变更时mysql 8.0+会静默跳过；再者禁止在触发器中修改自身表，否则报error 1442；错误常被吞，需执行show warnings或查错误日志定位。
触发器根本没被调用，先查是否启用
触发器“存在但不执行”最常见原因就是它被禁用了。MySQL 和 SQL Server 都不会报错、不提示、不写日志，它就安静地挂在那里。你执行 UPDATE 成功，@@rowcount 正常，但触发器逻辑压根没跑。
MySQL：运行 SELECT TRIGGER_NAME, STATUS FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'your_trigger_name';，确认 STATUS 是 ENABLED；若为 DISABLED，需重建（MySQL 5.7 不支持 ALTER TRIGGER ... ENABLE）
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
UPDATE 没改数据，触发器直接跳过
MySQL 8.0+ 默认行为：如果 UPDATE 语句未真正变更任何字段（例如 SET status = status 或 SET name = 'old' 而当前值就是 'old'），整个触发器会被静默跳过。
执行后立刻查 SELECT @@row_count; —— 若为 0，说明没命中行或无实际变更
检查 SELECT @@sql_mode;，若含 STRICT_TRANS_TABLES，这种无效更新会报错并中断；若不含，则可能静默跳过触发器
别信应用层返回的 “Query OK” —— 它只表示语法合法，不代表触发器跑了
触发器里改了自己这张表，直接报错中断
MySQL 禁止在触发器中修改触发它的同一张表，这是硬限制，不是配置问题。一旦出现，直接报错 ERROR 1442 (HY000)，且整个 DML 语句失败，但部分客户端不显示该错误。
常见场景：AFTER UPDATE 里又对本表做 UPDATE；或 BEFORE INSERT 里查本表最大 ID 再赋值
错误不会出现在 SHOW WARNINGS 里，得看 MySQL 错误日志（log_error 文件），搜 ERROR 1442
替代方案只有两个：把逻辑移到应用层（INSERT 后立刻 UPDATE），或改用 EVENT 异步处理
错误被吞掉，根本看不到真实原因
触发器内出错，MySQL 默认不抛给客户端，而是让主语句失败或静默中断。你以为“没执行”，其实是执行到一半崩了，输出被吞了。
执行完疑似触发失败的 INSERT/UPDATE 后，立刻运行 SHOW WARNINGS;，常能捕获触发器内部的真实错误，比如 Unknown column 'xxx' in 'field list'
打开 MySQL 错误日志：SET GLOBAL log_warnings = 2;，并确认 log_error 指向可读路径（如 /var/log/mysql/error.log），关键词搜 ERROR + 表名 + 触发器名
SQL Server 中，PRINT 或 RAISERROR 输出需客户端开启 SET NOCOUNT OFF 才能看见；否则你以为没执行，其实是输出被屏蔽了
真正卡住人的地方，往往不是语法写错，而是触发器压根没被调用——状态是 DISABLED、UPDATE 没改数据、或者错误日志没开。别急着重写逻辑，先验证它到底跑没跑。
