直接写join会卡死或超时，根本原因是优化器选错驱动表、索引覆盖不足导致全表扫描叠加和笛卡尔积预计算；必须为每个join字段建匹配on条件顺序的复合索引，拆分join至临时表并显式索引，或用straight_join/enable_seqscan强制执行计划。
为什么直接写 JOIN 会卡死或超时？
三个以上千万级表做 JOIN，MySQL 或 PostgreSQL 很容易出现执行计划崩坏：优化器选错驱动表、临时表爆内存、全表扫描叠加导致 EXPLAIN 显示 type=ALL 和 rows 高达亿级。根本原因不是 SQL 写法“不对”，而是默认连接顺序和索引覆盖不足让数据库被迫做笛卡尔积预计算。
必须给每个 JOIN 字段加复合索引，且顺序要匹配 ON 条件
比如 SELECT * FROM a JOIN b ON a.id = b.a_id JOIN c ON b.id = c.b_id，不能只在 b.a_id 上建单列索引。要建：
-
CREATE INDEX idx_b_a_id_id ON b (a_id, id)—— 让b表能被a快速定位后，直接按id走索引找下一级 -
CREATE INDEX idx_c_b_id ON c (b_id)—— 如果c是末尾表，单列够用；但若还要WHERE c.status = 1，就得改成(b_id, status) - 注意：
a.id和b.id本身是主键，不用额外建；但外键字段没索引就等于没约束
把大表 JOIN 拆成两段，中间结果走临时表或物化 CTE
三表关联不要一口气写完。先 a JOIN b → temp_ab，再 temp_ab JOIN c。关键点：
- 用
CREATE TEMPORARY TABLE temp_ab AS SELECT ...显式落盘，避免优化器重排执行顺序 - 对
temp_ab立即建索引：CREATE INDEX idx_temp_ab_b_id ON temp_ab (b_id) - PostgreSQL 可用
WITH RECURSIVE或普通 CTE，但必须加MATERIALIZED（v12+），否则仍是逻辑视图不物化 - MySQL 8.0+ 的 CTE 默认不物化，得靠
CREATE TABLE ... AS WITH ...强制固化
用 STRAIGHT_JOIN（MySQL）或 ENABLE_SEQSCAN=off（PG）干预执行计划
当 EXPLAIN 显示驱动表错误（比如拿最大表做驱动），硬控比等优化器靠谱：
- MySQL 加
STRAIGHT_JOIN：写成SELECT STRAIGHT_JOIN * FROM small_table s JOIN big_table b ON ...，强制s为驱动表 - PostgreSQL 设置
SET enable_seqscan = off临时关闭全表扫描，逼它用索引（仅调试用，别放生产） - 检查
JOIN字段类型是否严格一致：INT对BIGINT、VARCHAR(50)对VARCHAR(100)都会导致索引失效
真正难的不是写出能跑的 SQL，而是让每张大表在关联时只触达必要行数。索引字段顺序、中间结果是否物化、驱动表是否可控——这三个点漏掉任何一个，性能就断崖下跌。
