触发器未生效的首要原因是未被触发而非逻辑错误，常见于 REPLACE INTO 或 INSERT … ON DUPLICATE KEY UPDATE 不触发 BEFORE INSERT、条件不匹配、IF 提前退出、LOAD DATA 等操作默认不触发，以及隐式类型转换导致判断失效。
触发器没生效？先确认它是否真在运行
MySQL 触发器不会报错就“静默失效”，但常见情况是：它压根没被触发——不是逻辑错了，而是条件没满足。比如你写了 BEFORE INSERT，但实际执行的是 REPLACE INTO 或 INSERT …… ON DUPLICATE KEY UPDATE，这两种操作在某些 MySQL 版本中 ** 不触发 BEFORE INSERT**（尤其是 8.0.19 之前），只可能触发 BEFORE UPDATE。
- 用
SHOW TRIGGERS LIKE 'table_name';确认触发器状态为Enabled，且Timing和Event匹配你的操作（如INSERT对应BEFORE INSERT） - 检查触发器里有没有
IF条件提前LEAVE或RETURN，导致主体逻辑跳过 - 注意：触发器对通过
LOAD DATA INFILE、mysqlimport或并行复制应用的 binlog 事件 ** 默认不触发 **（除非显式启用binlog_format=ROW且配置了replicate-rewrite-db类规则）
UPDATE 语句绕过了触发器？检查 SQL 模式和隐式转换
一个典型坑是：你写了 BEFORE UPDATE 想校验金额不能超限，但用户传入字符串 '1000.00'，而字段是 DECIMAL(10,2) ——MySQL 在比较前会做隐式类型转换，可能让 IF NEW.amount > 5000 判断失效，甚至因转换失败让整个触发器中断（取决于 sql_mode）。
- 执行
SELECT @@sql_mode;，如果含STRICT_TRANS_TABLES或STRICT_ALL_TABLES，类型错误会报错并终止触发器；若不含，可能静默转成 0 或截断 - 在触发器开头加日志验证：用
INSERT INTO debug_log VALUES (NOW(), 'trigger_fired', NEW.id, NEW.amount);（需提前建表），看是否真进来了 - 避免依赖隐式转换：显式用
CAST(NEW.amount AS DECIMAL(10,2))或IFNULL(NEW.amount, 0)
触发器里改了数据，但主表更新却丢失了
这通常不是“丢失”，而是触发器逻辑覆盖了原始值。例如你在 BEFORE UPDATE 里写了 SET NEW.balance = OLD.balance + NEW.delta;，但业务代码又在 UPDATE 里显式设了 balance = 1000 ——最终以触发器里的 NEW.balance 为准，外部赋值被忽略。
-
BEFORE触发器中修改NEW.xxx会直接覆盖 SQL 语句中给出的值；AFTER触发器无法修改当前行数据（会报错Can't update table't' in stored function/trigger） - 如果需要“条件性覆盖”，必须在触发器里完整判断：比如原语句想设
status = 'paid'，但触发器要根据余额决定设成'pending'还是'failed'，那就得把所有分支写全，不能只写一个IF - 避免在触发器里调用存储过程修改同一张表，极易引发
Can't reopen table错误
怎么快速验证触发器逻辑是否符合预期
别等上线出问题再查。最有效的方式是用最小可复现 SQL 直接测，而不是靠应用走一遍流程。
- 准备干净测试数据：
INSERT INTO account VALUES (1, 1000.00, 5000.00); - 手动模拟业务操作：
UPDATE account SET balance = balance + 2000 WHERE id = 1; - 立刻查结果：
SELECT * FROM account WHERE id = 1;，再查关联表或日志表确认副作用是否发生 - 关键点：测试时关闭 autocommit（
SET autocommit = 0;），方便出错后ROLLBACK，避免污染数据
最容易被忽略的是触发器的执行顺序：多个同类型触发器（如两个 BEFORE INSERT）按创建时间升序执行，但 MySQL 不保证跨库或跨表触发器的全局顺序——如果你依赖 A 表触发器改完后再由 B 表触发器读取，这种设计本身就不可靠。
