触发器内子查询性能差，因其强制在每行DML事务中重复执行全表扫描、索引查找及嵌套JOIN，无法缓存或优化，且不走索引时易退化为全表扫描，1000行更新即触发1000次低效查询。
因为触发器内执行复杂子查询时，会把原本可异步或批量处理的逻辑，强行塞进每个DML事务的原子执行路径里——子查询每执行一次，就多一次全表扫描、多次索引查找、甚至嵌套循环JOIN，而这些操作在触发器中无法被缓存、无法被优化器重写，且必须在事务提交前完成。
触发器中子查询无法走索引的典型场景
当子查询引用 NEW 或 OLD 的字段但未在关联条件中使用索引列时，MySQL往往放弃使用索引。例如：
CREATE TRIGGER tr_update_score AFTER UPDATE ON user_info
FOR EACH ROW
BEGIN
INSERT INTO leaderboard (user_id, score)
VALUES (NEW.id, NEW.score + (
SELECT COALESCE(SUM(bonus), 0)
FROM user_bonus b
WHERE b.user_id = NEW.id -- ✅ 这里能用索引（假设 user_id 有索引）
)) ON DUPLICATE KEY UPDATE score = VALUES(score);
END;但如果写成：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
WHERE b.status = 'active' AND b.user_id = NEW.id -- ❌ 若 status 字段无索引，或联合索引顺序不对，整个子查询可能退化为全表扫描
- 即使
user_id有索引，status无索引或不是联合索引最左前缀，优化器大概率放弃索引 - 触发器每更新一行，该子查询就执行一次；1000行更新 = 1000次全表扫描
-
EXPLAIN在触发器内部不可见，你无法直接分析其执行计划
多层嵌套子查询在触发器中的放大效应
子查询本身在普通 SELECT 中已属高开销操作，在触发器中更危险：它不仅消耗CPU，还延长锁持有时间，阻塞其他事务。
- 一个三层嵌套子查询（如
(SELECT ... FROM (SELECT ... FROM (SELECT ...)))）在触发器中执行时，每一层都需独立构造临时结果集 - MySQL 5.7+ 对触发器中子查询的物化（materialization）策略保守，常拒绝优化，强制重复计算
- 若子查询含
GROUP BY或ORDER BY，还会触发 filesort 和临时表，进一步吃光CPU和内存 - 触发器最大嵌套层级默认为15，但实际业务中2层嵌套+JOIN就足以让单次UPDATE耗时从毫秒级升至秒级
为什么 SHOW PROCESSLIST 看不到问题子查询？
触发器内的SQL不会单独出现在 SHOW PROCESSLIST 的 INFO 列中——你只看到外层DML语句，比如 UPDATE user_info SET score = 100 WHERE id = 123，而真正吃CPU的子查询完全隐藏在执行引擎内部。
-
INFORMATION_SCHEMA.PROCESSLIST只显示客户端发起的语句，不展开触发器体 - 慢日志（
slow_query_log）默认也不记录触发器内部SQL，除非开启log_slow_slave_statements并配合特殊配置 - 真正有效的排查方式是：在触发器中加
SELECT SLEEP(0.001)占位后观察perf top或pt-pmp输出，看subselect_exec或evaluate_join_record是否高频出现 - 更务实的做法是——只要触发器里出现
SELECT带FROM子句，先默认它是潜在CPU热点
最容易被忽略的一点：触发器里的子查询没有查询缓存（Query Cache 已在 MySQL 8.0 移除，且即使5.7也对触发器无效），也没有执行计划复用机制；每次调用都是“冷启动”，连预编译都跳过。这不是性能差的问题，而是设计层面的不可控。
