lateral是mysql 8.0.14+引入的横向连接机制，非语法糖，而是执行模型变革：它使子查询能引用左表字段并逐行执行，适用于取每行最新关联记录等动态场景；需配合联合索引，否则退化为慢查询。
MySQL 8.0 的 LATERAL 是什么，它真能简化关联？
能，但只在特定场景下——当你需要对左表每行执行一个「依赖右表字段的子查询」，且该子查询不能提前物化（比如要取最新一条关联记录、按动态条件 LIMIT）时，LATERAL 才真正不可替代。它不是语法糖，而是让原本必须用窗口函数 + 多层嵌套或应用层拆分的逻辑，能在单条 SQL 中清晰表达。
常见误用是拿它替代普通 JOIN：如果右表查询不依赖左表字段（如 SELECT * FROM t1 JOIN (SELECT ... ) t2），加 LATERAL 反而降低可读性且无收益。
LATERAL 子查询里能写哪些内容？
必须是派生表（即括号包裹的 SELECT），且允许引用左侧表的列；不能是标量子查询（如 (SELECT name FROM users WHERE id = t1.user_id)），也不能是不含 FROM 的表达式。
- ✅ 支持
ORDER BY+LIMIT 1取最新关联项（如最近订单） - ✅ 支持
WHERE中使用左表字段做动态过滤（如WHERE o.status = t1.default_status） - ❌ 不支持直接引用左表别名在子查询的
SELECT列表中（需在FROM或WHERE中体现依赖） - ❌ 不支持子查询中再嵌套另一个
LATERAL（MySQL 8.0 当前限制）
示例：查每个用户最新一笔已完成订单
SELECT u.id, u.name, o.order_id, o.amount FROM users u LATERAL ( SELECT order_id, amount FROM orders o2 WHERE o2.user_id = u.id AND o2.status = 'completed' ORDER BY o2.created_at DESC LIMIT 1 ) AS o;
为什么有时 LATERAL 比窗口函数更合适？
核心在于执行语义：窗口函数先全量计算再过滤，LATERAL 是按左表逐行触发子查询，天然支持「早停」（如 LIMIT 1 能立刻终止扫描）；当右表数据量大、匹配率低时，性能差异明显。
- 用窗口函数得写
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)再外层WHERE rn = 1，MySQL 需扫描全部订单记录 - 用
LATERAL，对每个用户最多只扫一条匹配记录（索引有效时） - 注意：右表必须有合适索引，如
(user_id, status, created_at)，否则LATERAL的逐行查询会退化成全表扫描
容易被忽略的兼容性与调试陷阱
LATERAL 是 MySQL 8.0.14 引入的特性，低于此版本会报错 ERROR 1064 (42000): You have an error in your SQL syntax；即使 8.0.x，也要确认 sql_mode 未禁用扩展语法（默认开启）。
- 错误现象：语句在 8.0.13 或更低版本运行失败，但文档写着「8.0 支持」——实际要看小版本号
- 调试技巧：把
LATERAL子查询单独拿出来，代入一个具体左表值执行，验证逻辑和性能 - 注意别名作用域：
LATERAL子查询里的表别名对外不可见，外部不能直接引用o2.created_at，只能通过LATERAL的输出别名（如上例的o）访问
真正复杂的点不在语法，而在判断「是否真的需要逐行求值」——多数关联用普通 JOIN 或 EXISTS 更直白，LATERAL 是窄口径的利器，不是通用扳手。
