mysql 5.7子查询慢的根本原因是默认不启用索引下推（icp）且对相关子查询采用嵌套循环执行，导致外层每行都重执行内层查询；升级到8.0需手动确认icp开启、重构联合索引并验证执行计划。
MySQL 5.7 处理复杂子查询慢，根本原因不是版本低，而是执行策略和索引利用方式落后——它默认不启用索引下推（ICP），且对相关子查询仍用嵌套循环执行，外层每行都重跑内层，没物化缓存。升级到 8.0 并不能自动变快，必须配合 index_condition_pushdown 开启、联合索引重构和执行计划验证。
MySQL 5.7 子查询为何卡在“每行重执行”
5.7 对 IN、EXISTS 类相关子查询，默认走 nested-loop 执行：外层查出 1 行，就触发一次完整子查询解析+执行。如果外层结果有 10 万行，子查询就被调用 10 万次——哪怕内层表只有几千行，I/O 和解析开销也爆炸。
- 典型表现：
EXPLAIN中select_type为SUBQUERY或DEPENDENT SUBQUERY，且rows值反复出现（不是单个估算值） - 即使子查询本身带
WHERE条件，若字段无索引或顺序不对，5.7 也不会下推过滤，全量扫描后再内存过滤 -
NOT IN还额外触发临时表物化，NULL值处理逻辑更重，极易全表扫
MySQL 8.0 的 ICP 不是默认全开，得手动确认
8.0 默认开启 index_condition_pushdown，但只对支持的存储引擎（InnoDB）和特定访问类型（range、ref、eq_ref）生效；若子查询走 ALL 或 index 扫描，ICP 压根不介入。
- 检查是否真启用：
SELECT @@optimizer_switch LIKE '%index_condition_pushdown=on%';，返回 1 才算有效 - ICP 要求索引能覆盖子查询的
WHERE条件字段，比如SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'active' AND city = 'sh')，需在users(status, city, id)上建联合索引，否则 ICP 无法下推city过滤 - 注意：ICP 不解决 JOIN 字段类型不一致问题。若
orders.user_id是BIGINT UNSIGNED，而users.id是INT，即使有索引，ICP 也跳过
升级 8.0 后仍慢？先看 EXPLAIN 里有没有 Using index condition
这是 ICP 生效的唯一明确信号。没有它，说明优化器根本没把条件推到存储引擎层，还在 Server 层做全量回表过滤。
- 正确示例：
EXPLAIN SELECT ... WHERE u.id IN (SELECT user_id FROM orders WHERE created_at > '2026-01-01')，若orders(created_at, user_id)有索引，且Extra列含Using index condition，才算 ICP 起效 - 常见陷阱：子查询里用了函数，如
WHERE DATE(created_at) = '2026-05-01'，索引失效，ICP 自动失效 - 升级后别急着删旧索引——8.0 的索引统计信息更新机制不同，刚升级时可能用错执行计划，建议执行
ANALYZE TABLE orders;强制刷新
ICP 不是银弹。它只加速“索引扫描阶段的过滤”，不改变子查询本身的执行模型。真正要破局，还是得回到 EXISTS 替代、派生表预计算、或显式建临时表——这些动作在 5.7 和 8.0 上效果一致，但 8.0 的物化表支持哈希索引，临时表 JOIN 更快。别把性能赌在版本号上，赌在 EXPLAIN 的每一列里。
