LATERAL JOIN本身不优化查询，真正起效的是复合索引匹配、驱动条件置顶及避免嵌套逻辑；若子查询未走索引，外层N行将触发N次全表扫描，导致性能断崖式下降。
LATERAL JOIN 本身不优化查询，它只是让“每行触发一次子查询”这件事变得合法且可控；真正起优化作用的是你是否配对了复合索引、是否把驱动条件提到顶层、是否避免了嵌套逻辑。
为什么加了 LATERAL 后查询反而变慢
常见现象是 EXPLAIN 里看到 Lateral 节点下嵌套大量 Index Scan 或 Seq Scan，且 Actual Rows 高达几十万——这说明外层表返回 N 行，子查询就被执行了 N 次，而每次都没走高效索引。
- 子查询中用于关联的字段（如
orders.user_id）没落在复合索引最左前缀上：例如写WHERE user_id = u.id AND created_at >= $1，但只建了INDEX ON orders(user_id)，必须改成INDEX ON orders(user_id, created_at) - 用了
NOT EXISTS、OR嵌套或非标准函数（如FIND_IN_SET），导致优化器放弃索引下推 - 子查询里
WHERE过滤过早，比如把cst.remind = 1塞进OR分支里，而不是放在子查询顶层
LEFT JOIN LATERAL 和 JOIN LATERAL 的行为差异
这不是风格问题，而是结果集是否丢数据的分水岭：
-
JOIN LATERAL（等价于CROSS JOIN LATERAL）：子查询返回 0 行 → 外层该行被丢弃，效果类似INNER JOIN -
LEFT JOIN LATERAL：子查询返回 0 行 → 外层行保留，右侧所有字段为NULL - 必须显式写
ON true，漏掉会导致语义变成无条件笛卡尔积 - 典型反例：查“每个用户 + 最新订单”，但有些用户从未下单——用
JOIN LATERAL就会直接丢掉这些用户
怎么写一个安全、可索引的 LATERAL 子查询
核心是让 PostgreSQL 能在子查询中快速定位到匹配行，而不是扫描全表：
- 外层表必须显式别名（如
base），子查询中引用字段必须带这个别名（base.user_id），不能写users.id - 子查询中所有驱动条件（即决定取哪些行的等值条件）必须放在
WHERE顶层，扁平化，避免嵌套在OR或NOT EXISTS里 - 复合索引字段顺序要严格匹配查询条件顺序：例如子查询是
WHERE cst.user_id = base.user_id AND cst.city = base.shopCity，索引就得是INDEX ON contract_signing_template(user_id, city) - 避免在子查询里调用未索引字段的过滤（如
AND status = 'active'却没给status建索引）
什么时候该放弃 LATERAL 改用其他方式
LATERAL 不是银弹，它暴露了执行计划的“逐行性”，一旦控制不好，性能会断崖式下跌：
- 当你要取 Top-N 中的 N 较大（如 Top-50）或分组总数很少（如只有 5 个部门），
ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)更稳 - 子查询里用了
LIMIT，PawSQL 等优化器就无法将其重写成解关联形式，失去自动优化机会 - 需要同时输出排名 + 累计占比（如
SUM() OVER ()），只能靠窗口函数，LATERAL 无法嵌套窗口 - 旧版 MySQL（5.7）、SQLite、部分云数据库不支持
LATERAL，强行使用直接报语法错误
真正难的不是写对语法，而是看懂 EXPLAIN ANALYZE 里那几层嵌套扫描是不是真走了索引——如果看到 Index Scan using xxx on orders 下面的 Rows Removed by Filter 高达 99%，说明索引没被有效利用，得立刻回退检查复合索引和 WHERE 条件位置。
