PostgreSQL 15 默认不重排 LEFT JOIN 顺序，因语义约束必须保留左表所有行；优化需靠括号控制连接优先级、确保字段类型一致、禁用低效算法并调大 work_mem。
PostgreSQL 15 默认不重排 LEFT JOIN 顺序，别信写的顺序
PostgreSQL 优化器对 LEFT JOIN 有语义约束：必须保留左表所有行。因此，它通常不会像 INNER JOIN 那样自由交换顺序——哪怕右表更小、过滤更强，只要写成 FROM a LEFT JOIN b ON ...，a 很可能就是实际驱动表。
常见错误现象是 EXPLAIN 显示 Seq Scan on b 被执行了上万次（对应左表 a 的每一行），尤其当 b 没索引或 ON 条件类型不匹配时。
- 用
EXPLAIN (ANALYZE, BUFFERS)看实际执行顺序，重点关注最外层节点的Plan Rows和子节点的Actual Loops；若后者远大于 1，说明右表被反复扫描 - 想让小结果集先算？把高过滤性的表挪到
FROM后第一个位置，哪怕业务上它不是“主表” - 避免在
LEFT JOIN右侧接无条件宽表（如config表），否则左表每行都触发一次全扫
用括号显式控制多表 JOIN 优先级
PostgreSQL 15 解析器按括号分组决定连接顺序，而非从左到右线性执行。没括号时，A JOIN B JOIN C 默认等价于 (A JOIN B) JOIN C；但你可以强制改成 A JOIN (B JOIN C)，让 B 和 C 先关联出小结果，再连 A。
这比依赖优化器更可靠，尤其当统计信息不准或 work_mem 不足导致哈希落盘时。
- 示例：想先聚合订单再关联合用户，写成
SELECT * FROM users u JOIN (SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY user_id) o ON u.id = o.user_id - 括号内子查询会物化（materialize），PostgreSQL 15 通常能准确估算其行数，从而选更优连接路径
- 注意：括号不能用于
LEFT JOIN的左侧（即不能(a LEFT JOIN b) LEFT JOIN c改成a LEFT JOIN (b LEFT JOIN c)），语义不同，可能改变 NULL 行行为
禁用低效算法 + 调整 work_mem 才能让顺序优化生效
即使你用括号写了理想顺序，优化器仍可能因代价误判选错连接方式——比如对中等规模等值连接选 Nested Loop 而非 Hash Join，结果驱动表顺序完全失效。
这时单纯调顺序没用，得配合底层策略干预：
- 临时禁用
Nested Loop：SET enable_nestloop = off，强制走Hash Join（适合内存充足、等值连接） - 增大
work_mem避免哈希落盘：SET work_mem = '128MB'（需结合并发数和shared_buffers调整，别设过高） - 执行后检查
EXPLAIN (ANALYZE, BUFFERS)输出里是否还有temp:行；若有，说明仍发生磁盘 spill，work_mem还不够
字段类型不一致会让所有顺序优化白做
如果 ON a.id = b.user_id 中 a.id 是 bigint，而 b.user_id 是 text 或 integer，PostgreSQL 会隐式转换其中一列——导致右表索引失效，退化为全表扫描。此时无论你怎么调顺序、加括号、改 work_mem，都只能眼睁睁看 Seq Scan on b 被执行 N 次。
真正要做的第一件事，是确认类型严格一致：
- 用
SELECT column_name, data_type FROM information_schema.columns WHERE table_name IN ('a', 'b');对比字段类型 - 特别注意符号性（
integervsbigint）、字符集（textvsvarchar(64)）、排序规则（COLLATE "default"是否相同） - 修复方式：统一类型（
ALTER TABLE b ALTER COLUMN user_id TYPE bigint USING user_id::bigint），或建函数索引（CREATE INDEX ON b ((user_id::bigint))）
顺序优化的前提是索引能被命中；而索引能被命中的前提，是类型不转换。这点最容易被忽略，也最致命。
