LATERAL可替代嵌套子查询提升性能，但仅MySQL 8.0.14+支持；低版本需用派生表模拟，须手动处理关联与索引优化。
直接用 LATERAL 替代多数嵌套子查询，能避免重复执行、绕过物化限制，但 MySQL 8.0.14+ 才支持；低于该版本，派生表 是更可控的替代方案，不过得手动处理关联依赖。
MySQL 8.0.14+ 中 LATERAL 的真实使用场景
LATERAL 允许子查询引用外部表字段，且对每行只执行一次——这正是传统相关子查询（DEPENDENT SUBQUERY）最慢的原因。它不是语法糖，而是执行模型的改变。
- 必须显式写
LATERAL关键字，FROM后紧接子查询，不能省略 - 子查询里可直接用外层表列，如
orders.id，无需再写WHERE关联条件 - 不支持在
WHERE或SELECT子句中用LATERAL；只能出现在FROM子句中 - 若子查询返回多行，会自动做
CROSS JOIN；返回 0 行则该外层行被丢弃（类似INNER JOIN语义）
示例：查每个订单最新一条物流轨迹
SELECT o.order_id, t.status, t.update_time FROM orders o LATERAL ( SELECT status, update_time FROM logistics t WHERE t.order_id = o.order_id ORDER BY update_time DESC LIMIT 1 ) AS t;
对比原来写法：SELECT ..., (SELECT ... FROM logistics WHERE order_id = o.order_id ORDER BY ... LIMIT 1) —— 这是 DEPENDENT SUBQUERY，EXPLAIN 显示 select_type=DEPENDENT SUBQUERY，性能随订单数线性恶化。
MySQL 5.7 / 8.0.14 之前用 派生表 模拟 LATERAL 的关键约束
派生表本质是“先算完再连”，无法直接引用外部表字段，所以必须把关联逻辑前置到子查询内部，靠 JOIN 或聚合兜底。
- 子查询必须包含所有需要关联的字段（如
order_id），否则外层无法ON连接 - 若要取“每个订单最新轨迹”，得先在派生表里
GROUP BY order_id+MAX(update_time)，再回连原表取完整行——两步走，容易漏数据 - MySQL 5.7 对派生表默认强制物化（
select_type=DERIVED），8.0+ 开启optimizer_switch='derived_merge=on'才可能合并优化 - 派生表字段无索引，
ON条件务必落在主键或已建索引列上，否则外层JOIN变成全表扫描
示例（安全但稍冗余）：
SELECT o.order_id, t.status, t.update_time FROM orders o JOIN ( SELECT order_id, MAX(update_time) AS max_time FROM logistics GROUP BY order_id ) AS latest ON o.order_id = latest.order_id JOIN logistics t ON t.order_id = latest.order_id AND t.update_time = latest.max_time;
LATERAL 和派生表都避不开的索引陷阱
无论用哪种结构，只要子查询里有 WHERE、ORDER BY 或 JOIN 条件，对应字段没索引，性能就直接掉档。
-
LATERAL子查询中的WHERE t.order_id = o.order_id要求logistics.order_id有索引，否则每次都在logistics全表扫 - 派生表中
GROUP BY order_id要求logistics.order_id是前导索引字段，否则触发Using temporary; Using filesort - 字符集/排序规则不一致会让所有索引失效：比如
orders.user_id是utf8mb4_0900_as_cs，而users.id是utf8mb4_general_ci，JOIN就用不上索引
验证方式统一：对最终 SQL 执行 EXPLAIN FORMAT=JSON，重点看 "key" 是否非空、"rows" 是否显著小于表总行数、"select_type" 是否仍是 DEPENDENT SUBQUERY。
真正难的不是选 LATERAL 还是派生表，而是判断子查询是否真有必要——很多所谓“复杂嵌套”，其实拆成两个简单查询+应用层合并，反而更快、更稳、更容易加缓存。
