mysql修改触发器后需drop再create，因不支持alter；sql server中触发器可能被禁用而不提示；mysql触发器内更新同表会报错1442但常被忽略；mysql 8.0+对无实际变更的update会静默跳过触发器。
修改触发器后没生效，大概率不是代码写错了，而是它根本没被加载或没被调用。
MySQL 修改触发器后必须 DROP 再 CREATE
MySQL 不支持 ALTER TRIGGER（5.7 及更早版本完全不支持；8.0+ 虽有语法但实际不刷新执行逻辑）。你执行 CREATE OR REPLACE TRIGGER 或直接改定义，数据库不会自动重编译、也不会更新内存中的触发器副本。
- 运行
SHOW CREATE TRIGGER trigger_name;，对比输出和你改后的代码是否一致 - 确认当前数据库上下文：跨库操作前必须
USE db_name;，否则SHOW TRIGGERS查不到 - 稳妥做法永远是：
DROP TRIGGER IF EXISTS trigger_name;→CREATE TRIGGER ... - 注意权限：
DROP TRIGGER需要TRIGGER权限，且对目标表有ALTER权限
SQL Server 中触发器被禁用却不提示
SQL Server 允许用 DISABLE TRIGGER 禁用单个触发器，但它不会报错、不记录日志、也不影响 DML 语句执行——你 INSERT 成功，@@rowcount 正常，但触发器逻辑一丁点都没跑。
- 查状态：
SELECT name, is_disabled FROM sys.triggers WHERE object_id = OBJECT_ID('your_table'); - 若
is_disabled = 1，执行：ENABLE TRIGGER trigger_name ON your_table; - 别信 SSMS 的“刷新”图标——它不自动 reload 触发器状态，必须手动查
sys.triggers - 批量启用：
EXEC sp_msforeachtable 'ENABLE TRIGGER ALL ON ?';（慎用）
触发器里写了 UPDATE 却没变，其实是 MySQL 硬限制报错被吞了
在 MySQL 的 BEFORE UPDATE 或 AFTER UPDATE 里对同一张表再做 UPDATE，会触发 ERROR 1442 (HY000)，整个语句失败。但很多客户端（尤其是 ORM 或 PHP mysqli 默认配置）不显示该错误，只返回 “Query OK”，让你误以为成功。
- 立刻执行
SHOW WARNINGS;—— 很可能看到Can't update table 'xxx' in stored function/trigger - 去 MySQL 错误日志搜
ERROR 1442，路径由log_error变量决定 - 别在触发器里写
UPDATE target_table SET ... WHERE id = NEW.id;这类语句 - 替代方案只有两个：把逻辑提到应用层（DML 后立刻发第二条 SQL），或改用
EVENT异步轮询
UPDATE 语句没真改数据，触发器被 MySQL 8.0+ 静默跳过
MySQL 8.0 开始，默认行为是：如果 UPDATE 没实际变更任何字段（比如 SET status = status 或 SET name = 'old' 而当前值就是 'old'），整个触发器会被跳过，不执行、不报错、不警告。
- 执行完 UPDATE 后马上查：
SELECT @@rowcount;—— 若为0，说明没命中行或无实际变更 - 检查 SQL 模式：
SELECT @@sql_mode;，若含STRICT_TRANS_TABLES，这种无效更新会直接报错中断；若不含，则静默跳过触发器 - 别依赖应用层返回的 “Affected rows: 1” —— 它只表示语句解析通过，不代表触发器跑了
- 调试时加日志：在触发器开头插入一行到 debug 表，再查这张表有没有新增记录
最麻烦的不是语法错，而是触发器看起来“运行了”，其实连第一行代码都没进——比如被禁用、被跳过、被隐式转换绕开条件判断，或者压根没重新创建。每次怀疑失效，先查状态、再看日志、最后验证是否真被调用，比反复改逻辑更省时间。
