当触发器未生效时，很多人第一反应是怀疑逻辑编写错误，但实际排查后发现，更多情况是触发器压根没有被调用，而非代码本身存在缺陷。
先别急着深究触发器内部的逻辑，从最基础的检查入手。
先确认触发器是否启用且匹配操作类型
MySQL 和 SQL Server 都不会主动提示“触发器已被禁用”，它只是安静地挂在那里。你执行了 UPDATE 语句，@@rowcount 也返回正常，但触发器代码却完全没有执行。如何确认？
- 在 MySQL 中，运行
SELECT TRIGGER_NAME, STATUS, EVENT_MANIPULATION, EVENT_OBJECT_TABLE FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'your_trigger_name';，重点关注STATUS是否为ENABLED，EVENT_MANIPULATION是否为UPDATE，EVENT_OBJECT_TABLE是否指向目标表名。 - 在 SQL Server 中，查询
sys.triggers，确认is_disabled = 0，且type_desc包含SQL_TRIGGER以及对应事件（例如UPDATE）。 - 还有个快捷方式
SHOW TRIGGERS LIKE 'table_name';，但它只查询当前数据库；若跨数据库操作，需要先执行USE db_name。
UPDATE 实际未修改数据，触发器被直接跳过
另一个常见陷阱是：UPDATE 语句本身没有产生任何实际变更。MySQL 8.0+ 的默认行为是：如果执行 SET status = status 或 SET name = 'old_name' 而当前值已经是 'old_name'，整个触发器会被静默跳过，既不报错也不执行。
- 执行后立即查询
SELECT @@row_count;—— 如果返回0，说明没有命中行，或者根本没有发生实际变更。 - 检查
SELECT @@sql_mode;，若包含STRICT_TRANS_TABLES，这种无效更新会报错并中断；若不包含，则可能静默跳过触发器。 - 不要过度依赖应用层返回的“Query OK”——它只表示语法合法，不意味着触发器已被执行。
触发器内编写了 UPDATE 却未生效，可能是修改了触发器自身所在的表
这是一个硬性限制，而非配置问题。MySQL 禁止在触发器中修改触发它的同一张表，一旦出现，就会直接报错 ERROR 1442 (HY000)，整个 DML 语句都会失败，但部分客户端可能不会显示该错误。
- 常见场景：在
AFTER UPDATE中又对本表执行UPDATE；或者在BEFORE INSERT中查询本表最大 ID 再赋值。 - 这个错误不会出现在
SHOW WARNINGS中，需要查看 MySQL 错误日志（log_error文件），搜索ERROR 1442。 - 替代方案只有两个：要么将逻辑迁移到应用层（INSERT 后立即 UPDATE），要么改用事件（
EVENT）异步处理。
错误信息被吞掉，根本看不到真实原因
触发器内部出错时，MySQL 默认不会把错误抛给客户端，而是让主语句失败或静默中断。你以为“没执行”，其实是执行到一半崩溃了，输出被屏蔽了。
- 执行完疑似失败的
UPDATE后，**立刻**运行SHOW WARNINGS;—— 通常能捕获真实错误，例如Unknown column 'xxx' in 'field list'。 - 开启错误日志：
SET GLOBAL log_warnings = 2;，并确认log_error指向可读路径（如/var/log/mysql/error.log），然后搜索关键词ERROR加上表名和触发器名。 - 不要在触发器内编写裸
SELECT语句（除非接INTO变量），否则会直接报错ERROR 1415，导致触发器加载失败。
还有一个容易被忽略的细节：你修改了表结构（比如重命名了字段），但没有同步更新触发器中的 NEW.xxx 引用，在大写敏感环境下（lower_case_table_names=0）尤其容易失效——它不会报错，只是读取不到值，后续逻辑全部空转。
