触发器没生效大概率是未被调用，首要排查是否启用且事件匹配：mysql查information_schema.triggers中status为enabled、event_manipulation和event_object_table正确；sql server查sys.triggers中is_disabled=0；update无实际变更时mysql 8.0+会静默跳过；禁止在触发器中修改自身表，否则报error 1442；错误常被吞，需执行show warnings或查error log定位。
触发器没生效，大概率它压根没被调用，而不是逻辑写错了。
先查触发器是否启用且匹配操作类型
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 实际没改数据，触发器直接跳过
MySQL 8.0+ 默认行为：如果 UPDATE 语句未真正变更任何字段（例如 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）尤其容易失效——它不报错，只是读不到值，后续逻辑全空转。
