lateral能引用前表字段是因为它显式声明子查询按行执行，每处理外层一行就动态绑定并重执行一次；普通子查询被sql标准视为独立作用域的预计算快照，执行时外层表尚未进入作用域，故无法访问t.id等字段。
为什么LATERAL能引用前表字段而普通子查询不能
普通子查询在执行时是独立作用域，FROM左侧的表还没“进来”，自然看不到t.id这类字段；LATERAL明确告诉数据库：这个子查询要按行执行，每处理t的一行，就拿该行数据去跑一次子查询——所以它能安全引用t.name、t.created_at等列。
PostgreSQL中LATERAL的基本写法和常见错误
必须加LATERAL关键字，漏掉就会报错ERROR: invalid reference to FROM-clause entry；子查询必须是表表达式（比如(SELECT ...)或VALUES），不能直接写SELECT裸语句。
正确示例：
SELECT t.id, t.name, s.tag FROM posts t LEFT JOIN LATERAL ( SELECT tag FROM post_tags WHERE post_id = t.id ORDER BY created_at DESC LIMIT 1 ) s ON true;
容易踩的坑：
-
LATERAL后面必须跟括号包裹的子查询，写成JOIN LATERAL SELECT ...会语法错误 - MySQL不支持
LATERAL（8.0.14+才支持，且仅限FROM子句，不支持JOIN后直接跟） - 如果子查询返回多行但没用
JOIN条件约束，可能引发笛卡尔积——别依赖ON true来“兜底”
替代方案：哪些情况其实不该用LATERAL
当子查询只取单个标量值（比如最新评论时间），用SELECT ... FROM t LEFT JOIN LATERAL (SELECT MAX(created_at) FROM comments WHERE post_id = t.id) c ON true可行，但更简洁的是用窗口函数或关联子查询：
SELECT id, name, (SELECT MAX(created_at) FROM comments WHERE post_id = posts.id) AS latest_comment_at FROM posts;
这时候用LATERAL反而增加理解成本；只有当你需要子查询返回多列、多行，或要复用计算逻辑（比如JSON解析、数组展开）时，LATERAL的价值才明显。
性能敏感点：LATERAL不是银弹
数据库对LATERAL的优化程度因版本而异。PostgreSQL 12+会对简单LATERAL做内联展开，但遇到嵌套LATERAL或含复杂过滤时，可能退化为循环嵌套执行（N×M次）。
实操建议：
- 对大表慎用
LATERAL+ 无索引关联字段，先确保WHERE里用到的外键有索引 - 用
EXPLAIN ANALYZE看执行计划，确认是否出现Subquery Scan节点及实际循环次数 - 若子查询逻辑固定且轻量，考虑提前物化为CTE或临时表，避免重复计算
最常被忽略的是：LATERAL子查询里的ORDER BY ... LIMIT在没有合适索引时，每行都会触发一次全表扫描——这点比语法本身更致命。
