触发器内执行复杂查询会直接卡死写入链路，因其行级同步执行导致每行插入都重复全表扫描、锁表阻塞，且无法利用查询缓存或优化执行计划；应彻底移除join、聚合、子查询等操作，改用应用层预计算、冗余字段或异步队列。
触发器里执行复杂查询不是“不推荐”，而是会直接卡死写入链路——它让本该毫秒级完成的 INSERT 或 UPDATE 变成同步阻塞、锁住多张表、每行都重跑全表扫描的定时炸弹。
为什么复杂查询在触发器里等于性能雪崩
触发器是行级、同步、事务内执行的。你插 100 行，AFTER INSERT 就执行 100 次；每条里面有个 SELECT SUM(amount) FROM orders WHERE user_id = NEW.user_id，就等于扫 100 次用户订单表。哪怕有索引，优化器也不给触发器内的语句做驱动表重排或缓存执行计划，大概率退化为 Block Nested-Loop Join。
- MySQL 的
EXPLAIN完全不显示触发器内 SQL，你看到的“快 SQL”可能正被隐藏的SELECT COUNT(*)卡着 -
SHOW PROCESSLIST里大量线程卡在Sending data或Updating，但慢日志只记主语句，不标触发器名 - 批量
LOAD DATA INFILE时，触发器逐行调用，IO 和 CPU 开销线性放大，索引完全无效
哪些查询算“复杂”？一眼识别高危写法
只要满足以下任一条件，就属于应立即砍掉的复杂查询：
- 含
JOIN（哪怕只是LEFT JOIN config） - 带聚合函数：
COUNT()、SUM()、MAX()等 - 子查询出现在
WHERE中：WHERE id IN (SELECT ...)或相关子查询 -
SELECT *或没LIMIT 1的单点查询（如SELECT status FROM product WHERE id = NEW.product_id） - 查的表没主键/没索引，或
WHERE条件无法命中索引（比如用了UPPER(name)或LIKE '%xxx'）
替代方案不是“怎么优化它”，而是“让它别在这儿跑”
真正要解决的不是“让触发器里的 JOIN 快一点”，而是“能不能不在这儿查”。可行路径很明确：
- 必须实时校验？用覆盖索引 +
SELECT ... FOR UPDATE LIMIT 1，且只查一行 - 要聚合统计？改用应用层维护冗余字段（如用户表加
total_spent），触发器只做NEW.total_spent := OLD.total_spent + NEW.amount - 需跨表状态检查？提前物化到轻量汇总表（如
user_daily_summary），触发器只读这张表 - 完全无法绕开？走“落库即走”：触发器只写
INSERT INTO trigger_queue (table_name, row_id, event_type)，后台进程异步消费
最危险的不是触发器做了什么，是你根本看不见它做了什么；最麻烦的不是它慢，是你连它在哪慢都很难确认。一旦上线，问题往往只在高并发压测或主从延迟突增时才暴露，而那时回滚成本已经很高。
