LEFT JOIN超时主因是优化器编译阶段路径爆炸，而非执行慢；典型表现是未执行即报Timeout expired，需优先检查执行计划是否生成、JOIN字段索引及过滤条件位置。
LEFT JOIN 超时和左表大小没直接关系——真正卡住的是优化器编译阶段，不是执行阶段。
SQL Server 解析超时：LEFT JOIN 触发路径爆炸
当 LEFT JOIN 嵌套在视图、子查询或三张以上表关联中时，SQL Server 优化器在生成执行计划前会尝试穷举所有可能的连接顺序。但 LEFT JOIN 的语义强制左表必须作为驱动侧（不能像 INNER JOIN 那样自由切换），若左表虽小（比如 10 行），而右表是亿级且 customer_id 字段无索引，优化器就无法快速估算中间结果集大小，陷入“该不该用哈希？该不该下推过滤？该不该物化子查询？”的反复权衡，最终在编译阶段超时，报错 Timeout expired. The timeout period elapsed prior to completion of the operation。
- 这不是慢，是根本没开始执行
-
SET STATISTICS XML ON执行后看不到执行计划，就是典型解析超时 - 把最外层
LEFT JOIN临时改成INNER JOIN后秒出计划，基本可锁定问题根源
MySQL 中小左表仍慢：嵌套循环 + 全表扫描
MySQL 默认使用嵌套循环连接（Nested Loop Join）。即使左表只有 10 行，只要右表 ON 字段没索引，每行都要扫一遍右表全量数据。10 行 × 5000 万行 = 5 亿次比对，内存打满、磁盘 IO 拉满，触发 wait_timeout 或被 OOM killer 终止。
- 用
EXPLAIN看type是ALL，rows显示右表总行数，就是这个症状 -
key列为NULL表示没走索引 - 别信“左表小就安全”——驱动表小 ≠ 被驱动表不扫全表
过滤条件写错位置：WHERE 在 JOIN 后导致无效下推
写成 LEFT JOIN ... WHERE o.status = 'shipped'，数据库无法把 o.status 过滤下推到右表扫描前，只能先完成全部 LEFT JOIN（包括大量 NULL 行），再过滤。右表哪怕有索引，也因语义限制无法生效。
- 正确做法：用子查询提前过滤右表，例如
(SELECT * FROM orders WHERE status = 'shipped') o - 或改用
INNER JOIN+ 条件，让优化器有下推空间 - 视图里定义了
LEFT JOIN，外部再加WHERE右表字段，等于白建索引
临时表未建索引：分批救急反而更慢
有人发现大表 JOIN 慢，就用 CREATE TEMPORARY TABLE tmp AS SELECT ... 先缓存右表子集，再 JOIN。但如果忘了给 tmp 的关联字段建索引，后续 JOIN 依然全表扫描，性能比原 SQL 还差。
- MySQL：建完立刻
ALTER TABLE tmp ADD INDEX idx_user_id (user_id) - PostgreSQL：先
CREATE TEMP TABLE tmp (...) WITH NO DATA，再INSERT，最后CREATE INDEX，避免锁表太久 - CTE（
WITH）不能建索引，500 万行以上慎用
最容易被忽略的一点：LEFT JOIN 的保全语义会让优化器放弃很多常规优化手段——它不是“写错了”，而是“设计上就拒绝妥协”。所以调优不能只盯着数据量，得先看执行计划有没有出来、ON 字段有没有索引、过滤有没有被下推、临时结构有没有索引支撑。
