DEPENDENT SUBQUERY 是性能硬伤，需改写为派生表 JOIN 或窗口函数；LATERAL 仅对等值关联有效；字段必须显式别名并加表前缀。
子查询慢，八成是被标记为 DEPENDENT SUBQUERY，每行外层数据都触发一次独立执行——这不是语法问题，是执行模型决定的硬伤。直接优化子查询本身意义不大，关键在绕过它。
为什么 EXPLAIN 里出现 DEPENDENT SUBQUERY 就该警觉
MySQL 在执行计划中打出这个标签，等于告诉你：对主表每一行，都要重新解析、连接、查索引、甚至建临时表来跑一遍子查询。10 万行？就是 10 万次重复开销。
- 哪怕子查询只返回 1 行，也不能复用结果；
- 即使内表有完美索引，外层驱动方式仍可能让索引下推失效；
-
IN (SELECT ...)和= (SELECT ...)都可能触发，但后者更危险（易报错或 NULL 语义异常）； - 在 MySQL 8.0 中，
optimizer_switch='materialization=on'对非相关子查询有效，但对DEPENDENT类型基本无效。
把相关子查询转成派生表（Derived Table）再 JOIN
核心思路：把“每行都算一次”变成“先算一次，再关联”。派生表强制物化，且 MySQL 8.0 对 FROM (SELECT ...) 形式有较成熟的物化与索引下推支持。
- 原写法（慢）：
SELECT u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) cnt FROM users u; - 改写后（快）：
SELECT u.name, COALESCE(o.cnt, 0) cnt FROM users u LEFT JOIN (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id) o ON u.id = o.user_id; - 必须确保派生表里
GROUP BY字段和ON条件字段完全一致，否则无法利用哈希连接或索引； - 如果派生表结果很大（比如百万级
user_id），加FORCE INDEX或提前在orders(user_id)上建索引比加LIMIT更可靠； - 别用
USING(user_id)，显式写ON u.id = o.user_id，避免列名歧义导致隐式转换。
LATERAL 不是银弹：哪些场景它真有用
MySQL 8.0 支持 LATERAL，但它只在特定结构下能规避重复执行——前提是子查询里的关联条件是等值且可下推的。一旦带非等值（如 、<code>BETWEEN），优化器大概率放弃物化，退化回相关子查询。
- 可行示例：
SELECT u.id, u.name, l.ip FROM users u LATERAL (SELECT ip FROM logins l2 WHERE l2.user_id = u.id ORDER BY created_at DESC LIMIT 1) l;——l2.user_id = u.id是等值，可走索引； - 不可行示例：
(SELECT ip FROM logins l2 WHERE l2.user_id —— <code> 导致无法下推，<code>LATERAL失效，仍是 N×M； -
LATERAL派生表不能引用外层多于一层的字段（比如嵌套 CTE 里的上两层别名），否则报错Unknown column； - 若需排序+分页（如最新 3 条登录），优先用窗口函数
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，比LATERAL + LIMIT更稳定。
标识符命名与别名冲突最容易被忽略
派生表字段若未显式别名，在 SELECT 列表或 WHERE 中直接引用，MySQL 可能因解析顺序报错或取错值——尤其当外层和派生表有同名列时。
- 错误写法：
SELECT id, name, cnt FROM users u LEFT JOIN (SELECT user_id, COUNT(*) FROM orders GROUP BY user_id) o ON u.id = o.user_id;——o的子查询没给COUNT(*)起名，cnt会报Unknown column； - 正确写法：
SELECT u.id, u.name, COALESCE(o.cnt, 0) FROM users u LEFT JOIN (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) o ON u.id = o.user_id; - 所有参与
JOIN的字段，无论内外表，都建议加表前缀（如u.id、o.user_id），避免STRICT_TRANS_TABLES模式下因歧义报错； - 派生表名不要用
t1、t2这类无意义别名，换成order_counts、active_users等，方便后续维护和 EXPLAIN 分析定位。
