AFTER触发器中子查询严重伤性能，因其行级同步执行、全表扫描、锁冲突及索引失效，导致单条INSERT从0.3ms飙升至20ms+；应移出触发器，改用应用预计算、异步消息或物化视图。
为什么AFTER触发器里的子查询特别伤性能
AFTER触发器中嵌套子查询（比如SELECT COUNT(*) FROM orders WHERE user_id = NEW.user_id）不是“慢一点”，而是会让单条INSERT从0.3ms飙升到20ms+。因为它是行级同步执行的——每插入一行，就全表扫描一次用户历史订单；1000 QPS时，数据库线程池直接排队卡死。
常见错误现象：SHOW PROCESSLIST里大量线程卡在Sending data或Updating；EXPLAIN ANALYZE显示Seq Scan扫描行数超10万；慢日志里Rows_examined动辄几十万。
- 子查询在AFTER阶段执行，此时主行已持X锁，再查关联表极易形成锁等待甚至死锁
- MySQL 8.0+对AFTER触发器中子查询的锁行为更严格，5.7上能跑通的逻辑，在8.0可能直接报
Deadlock found when trying to get lock - 子查询无法利用NEW字段的隐式索引——如果
orders.user_id是BIGINT而NEW.user_id是INT，类型不一致导致索引失效
把子查询逻辑移出触发器的三种可行路径
别纠结“怎么优化子查询”，先问：它真必须在触发器里实时跑吗？90%的情况，答案是否定的。
-
优先用应用层预计算字段：在用户表加
total_spent列，INSERT订单时由应用传入NEW.total_spent := OLD.total_spent + NEW.amount，触发器只做简单赋值 -
改用异步消息解耦：触发器只写一条轻量记录到
trigger_queue表（含table_name、row_id、event_type），由独立消费者服务拉取后批量执行聚合 -
换用物化视图或定时任务：对非强一致性场景（如日报统计），删掉触发器，改用
CREATE MATERIALIZED VIEW（PostgreSQL）或每5分钟REPLACE INTO summary_table SELECT ...（MySQL）
实在要保留子查询？必须满足这四个条件
如果业务强要求实时、且不能改架构，那子查询必须被驯服，否则等于埋雷。
- 只能走主键或唯一索引单点查询，且必须加
LIMIT 1（例如SELECT id FROM users WHERE id = NEW.user_id LIMIT 1） - 禁用
IN (SELECT ...)和NOT IN——NULL会导致全表扫描；改用EXISTS或JOIN并确保关联字段类型完全一致 - 所有被查字段必须有覆盖索引，用
EXPLAIN确认type是const或ref，而非ALL或range - 避免在子查询里调用函数（如
to_date(NEW.ts_str)），先用局部变量存好解析结果，再用于WHERE条件
MySQL中AFTER触发器调用子查询的致命陷阱
MySQL对AFTER触发器有硬性限制，很多看似合理的写法会直接报错或引发隐式问题。
- 在AFTER INSERT中对同一张表执行UPDATE（如更新汇总行），会触发
Can't update table 't' in stored function/trigger错误 - 子查询若依赖
NEW.id（自增ID），在BEFORE中不可用、在AFTER中又无法再修改NEW，形成设计死锁 - 触发器内调用存储函数，而该函数含循环或嵌套子查询——这种组合会让
Handler_commit突增，监控里能看到大量隐式回滚 - 批量操作（如
INSERT INTO t VALUES (),(),()）会让子查询执行N次，10万行=10万次子查询，哪怕每次1ms也耗100秒
