PostgreSQL JOIN 优化指南

🎯 核心问题

当你查询多个表时，PostgreSQL 需要决定按什么顺序连接这些表 。表越多，可能的连接顺序就呈指数级增长，导致规划器思考时间过长。

---

📊 举个栗子

简单场景（3个表）

SELECT * FROM a, b, c WHERE a.id = b.id AND b.ref = c.id;

规划器有 3 种选择：

1. 先连 A+B，再连 C
2. 先连 B+C，再连 A
3. 先连 A+C，再连 B（效率差，不推荐）

表少无所谓，规划器能快速算出最优方案。

---

复杂场景（10+个表）

可能的连接顺序 = 数百万种！

规划器会：

• ❌ 放弃穷举所有可能（太慢）
• ✅ 改用"遗传算法"猜测（快但不一定最优）

---

🔧 解决方案：手动控制连接顺序

方法 1：用 JOIN 语法暗示顺序

-- ❌ 普通写法：规划器自由选择
SELECT * FROM a, b, c WHERE a.id = b.id AND b.ref = c.id;

-- ✅ 强制顺序：先连 B+C，再连 A
SELECT * FROM a JOIN (b JOIN c ON b.ref = c.id) ON a.id = b.id;

方法 2：调整配置参数

-- 让规划器严格遵守你写的 JOIN 顺序
SET join_collapse_limit = 1;

-- 控制子查询是否展开（默认 8）
SET from_collapse_limit = 8;

参数	作用	推荐值
join_collapse_limit	是否把 JOIN 打散重新规划	1（严格遵循）或 8（默认）
from_collapse_limit	是否把子查询展开到父查询	8（默认）

---

💡 实际应用场景

场景 1：规划器选了烂顺序

-- 你知道 A 和 B 先连最快，但规划器不知道
SELECT * FROM a JOIN b ON a.id = b.id, c, d, e WHERE ...;
-- 设置 join_collapse_limit = 1，强制先连 A+B

场景 2：视图嵌套导致性能差

-- 视图内部有复杂 JOIN，引用时会被展开
SELECT * FROM x, y, (SELECT * FROM a, b, c ...) AS ss WHERE ...;

-- 如果展开后表太多，规划器会卡住
-- 调低 from_collapse_limit 避免展开

---

🎓 最佳实践

1. 表少（≤7个）：不用管，让规划器自己玩
2. 表多（>7个） ：
   • 用显式 JOIN 语法提示顺序
   • 设置 join_collapse_limit = 1
3. 发现查询规划慢 ：
   • 用 EXPLAIN ANALYZE 看执行计划
   • 手动调整 JOIN 顺序对比性能
4. 外连接（LEFT/RIGHT JOIN） ：
   • 规划器自由度本来就小，通常不用干预
   • FULL JOIN 完全固定顺序

---

⚡ 一句话总结

表少让规划器自动优化，表多用手写 JOIN + 配置参数告诉它怎么连，避免它瞎猜导致性能差。

---