LATERAL用于高效关联每条订单的最新状态而不丢失主表字段，避免GROUP BY丢字段或窗口函数嵌套；需配合联合索引防全表扫描，MySQL 8.0.14+支持但有语法和稳定性限制。
为什么用 LATERAL 而不是 MAX(id) 或窗口函数？
因为历史记录表（比如 order_status_log）里一条订单可能有几十条状态变更，你只想关联出「每条订单的最新状态」，但又不能丢失订单主表的其他字段（如 customer_id、created_at）。用 GROUP BY order_id + MAX(updated_at) 会丢字段；用窗口函数得嵌套两层子查询；而 LATERAL 允许你在 JOIN 时对每一行动态执行子查询，天然支持“每行独立求最新”。
LATERAL 子查询必须写在 FROM 后且带别名
PostgreSQL 和较新版本的 MySQL（8.0.14+）支持 LATERAL，但语法约束很具体：子查询必须出现在 FROM 子句中，且必须显式声明别名（哪怕只用一次），否则报错 syntax error at or near "LATERAL"。
正确写法示例：
SELECT o.id, o.customer_id, l.status, l.updated_at FROM orders o LEFT JOIN LATERAL ( SELECT status, updated_at FROM order_status_log l2 WHERE l2.order_id = o.id ORDER BY updated_at DESC LIMIT 1 ) l ON true;
关键点：
-
LATERAL必须紧贴子查询前，不能写成LEFT JOIN (LATERAL ...) - 子查询里引用外部表字段（如
o.id）是合法的，这是LATERAL的核心能力 -
ON true是惯用写法——因为关联逻辑已全部在子查询WHERE中完成，不需要额外条件
性能陷阱：没加索引时 LATERAL 会变全表扫描
LATERAL 不是银弹。如果 order_status_log(order_id, updated_at) 缺少联合索引，每次子查询都会扫全表匹配 o.id，10 万订单 × 平均 5 条日志 = 50 万次扫描。
必须确保索引覆盖查询路径：
- PostgreSQL：建
CREATE INDEX idx_order_log_order_updated ON order_status_log (order_id, updated_at DESC); - MySQL：建
INDEX idx_order_log_order_updated (order_id, updated_at)（注意 MySQL 不支持DESC索引方向，但ORDER BY ... DESC LIMIT 1仍能走索引） - 验证是否走索引：用
EXPLAIN看子查询是否出现Index Scan或Using index
MySQL 8.0.14+ 的 LATERAL 不支持 ORDER BY ... LIMIT 在某些嵌套场景
MySQL 对 LATERAL 支持尚不完整。例如在 UNION ALL 子句里、或子查询里再嵌套 LATERAL，可能报错 This version of MySQL doesn't yet support 'LATERAL derived'。更隐蔽的问题是：当子查询含 ORDER BY updated_at DESC LIMIT 1，但 updated_at 有重复值时，MySQL 可能返回任意一条（无稳定排序），而 PostgreSQL 会按物理顺序补足。
稳妥做法：
- 在子查询中追加确定性排序，比如
ORDER BY updated_at DESC, id DESC - 若业务允许，优先用
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC, id DESC)配合 CTE，兼容性更好 - 确认 MySQL 版本：运行
SELECT VERSION();，低于 8.0.14 则直接不用LATERAL
真正麻烦的是多级时间戳嵌套——比如既要最新状态，又要该状态下最新操作人，这时候 LATERAL 嵌套两层就极易触发 MySQL 的限制，不如拆成两个独立的 LATERAL 关联，或者改用物化最新状态视图。
