SQL JOIN难优化的核心在于中间结果集易爆炸、优化器估算不准、连接顺序难穷举、索引易失效及分布式场景下数据倾斜。
SQL JOIN 查询难优化，核心在于它把多个表的行组合在一起，这个过程天然容易产生大量中间数据，而数据库优化器又常难以准确预估组合后的规模和代价。
JOIN 会指数级放大中间结果集
比如三张各 10 万行的表做 INNER JOIN，若连接条件选择性差（如都用通用状态字段），中间笛卡尔积可能达百亿行量级。优化器依赖统计信息估算行数，但直方图不精细、采样率低或数据倾斜时，估算偏差可达几个数量级，导致选错驱动表、错误放弃索引、误判哈希连接比嵌套循环更优。
连接顺序对性能影响极大，但优化器不一定选对
4 张表 JOIN 理论上有 24 种连接顺序，优化器需在有限时间内穷举或启发式剪枝。当存在多列关联、复合索引覆盖不全、或 WHERE 条件与 JOIN 条件交织时，最优顺序往往依赖具体数据分布——而统计信息无法完整表达这种上下文。例如先连 A-B 再连 C 可能走索引，但先连 B-C 再连 A 就只能全表扫描。
索引失效场景多且隐蔽
- JOIN 字段类型不一致（如 VARCHAR 与 CHAR 比较，隐式转换导致索引失效）
- ON 子句中对连接字段使用函数（UPPER(a.name) = UPPER(b.name)）
- LEFT JOIN 后在右表字段加 WHERE 条件（把外连接“降级”为内连接，却仍按外连接计划执行）
- 复合索引顺序与 JOIN + WHERE 条件不匹配（如索引是 (a_id, status)，但查询只用了 status 过滤）
分布式或大宽表场景下，网络与内存开销成为瓶颈
在分库分表或 MPP 架构中，JOIN 常触发跨节点数据重分布（Shuffle）。若连接键分布不均（如 90% 的订单都属于某几个大客户），就会出现“数据热点”，个别节点内存爆满、任务卡死。此时即使单机执行快，整体也跑不动——而 EXPLAIN 很难暴露这类运行时倾斜问题。
