AFTER INSERT未生效多因触发时机误选：BEFORE阶段无法读取刚插入行，依赖自增ID必须用AFTER；触发器内禁止修改触发表，需用临时表中转；WHERE字段须建索引，避免JOIN与子查询；多个触发器应合并优化。
触发器里用 AFTER INSERT 却没生效？检查是否误判了触发时机
MySQL 触发器不执行，十次有七次是时机选错了。比如你想在插入后更新另一张表的统计字段，但写了 BEFORE INSERT，结果新记录还没进表，你去查它自然查不到——不是语法错，是逻辑断层。
-
BEFORE阶段能改NEW的值，但不能读取本表刚插入的行（因为还没写入） -
AFTER阶段可以安全读本表、关联其他表，但不能修改NEW或OLD - 如果依赖刚插入的自增 ID 做后续操作（比如写日志表），必须用
AFTER INSERT，BEFORE里NEW.id是 0 或 NULL
WHERE 条件写在触发器体里？别这么干，会全表扫
触发器内部没有索引优化，所有 SELECT 或 UPDATE 都按普通语句走。常见错误是：在 AFTER UPDATE 里写 UPDATE stats SET cnt = cnt + 1 WHERE user_id = NEW.user_id，看着没问题，但如果 stats.user_id 没建索引，每次更新都会全表扫描。
- 务必确保触发器中涉及的所有
WHERE字段都有对应索引，尤其是外键或高频查询列 - 避免在触发器里做多表 JOIN 或子查询，尤其不要
SELECT ... FROM other_table WHERE x IN (SELECT y FROM inserted)这类嵌套 - 如果业务允许，把聚合逻辑移到应用层或定时任务，触发器只做轻量标记（如设
is_dirty = 1）
触发器报错 Can't update table 't' in stored function/trigger 怎么办
这是 MySQL 的硬限制：触发器里不能修改当前正在被触发的表。比如对 orders 表建 AFTER INSERT，里面又写 UPDATE orders SET status = 'processed'，直接报错。
- 唯一绕过方式是用临时表中转：先
INSERT INTO tmp_order_ids SELECT NEW.id，再由外部脚本或事件轮询处理 - 更稳妥的做法是放弃“自动修正”，改为在应用层保证插入数据的完整性，触发器只负责旁路动作（发消息、记日志、更新无关表）
- 注意存储函数也有同样限制，别在函数里调用含触发器的表
多个触发器叠加导致性能崩了？优先合并而非禁用
一个表上堆了 5 个 AFTER UPDATE 触发器，每个都查一次用户表、写一次日志、发一次 MQ，TPS 直接腰斩。这不是触发器本身慢，是重复 IO 和锁竞争造成的。
- 把功能相近的触发器合并成一个，用
CASE WHEN区分不同字段变更（如IF OLD.status != NEW.status THEN ... END IF） - 避免在触发器里调用存储过程，除非该过程已确认无副作用且足够轻量
- 上线前用
SHOW TRIGGERS LIKE 'table_name'梳理存量，删掉长期未维护或已被应用层接管的旧触发器
最麻烦的从来不是写触发器，而是它悄无声息地把主键更新变成全表锁，或者在批量导入时让事务卡住十几秒才报错。上线前一定要在真实数据量下跑一遍 INSERT ... SELECT 和 LOAD DATA 场景。
