多重JOIN查询慢的主因是被驱动表无索引、驱动表结果集未压缩、两表JOIN字段类型不一致；需严格校验字段类型与长度、为被驱动表JOIN字段单独建索引、调整optimizer_search_depth=0以降低优化器开销。
多重 JOIN 查询慢，90% 以上不是 SQL 写得差，而是被驱动表没索引、驱动表结果集没压下来、或两表 JOIN 字段类型不一致——这三个点没对，调参、改写法、换算法全是白忙。
为什么 EXPLAIN 显示 type=ALL 却还在走 JOIN
这说明被驱动表的关联字段完全没走索引。比如 ON a.user_id = b.id，但 b.id 没建索引，或者 a.user_id 是 INT 而 b.id 是 VARCHAR，隐式转换直接让索引失效。
- 用
SHOW CREATE TABLE对比两表 JOIN 字段的类型、长度、是否允许NULL，必须严格一致 - 被驱动表的 JOIN 字段要单独建索引，别指望联合索引的“最左前缀”能兜底——除非它是联合索引第一列
-
EXPLAIN中看key列是否为NULL，rows是否远超预期；如果是，索引根本没生效
optimizer_search_depth=0 真的能救多表 JOIN 吗
能，而且见效快。MySQL 默认 optimizer_search_depth=62，表数 ≥ 8 时优化器会穷举连接顺序，CPU 全花在“想怎么连”上，而不是“怎么执行”。你看到的现象通常是：EXPLAIN 本身就要几秒，而实际数据量很小。
- 设为 0 不是关优化器，而是启用动态剪枝：内部按
min(表数量, 7)自动限深 - 20 表 JOIN 从 5 秒降到 50ms 很常见，执行计划质量通常不降
- 仅会话级生效：
SET optimizer_search_depth=0；全局需写入my.cnf并重启 - 不适合依赖固定执行计划做压测或审计的场景——计划可能随表数微调而变
LEFT JOIN 为什么有时比 INNER JOIN 还慢
因为优化器可能把右表当驱动表，甚至悄悄转成 INNER JOIN。典型表现是 EXPLAIN 里出现 Using where; Using join buffer，说明走了 Block Nested-Loop（BNL），性能断崖下跌。
- 这不是 LEFT 的错，而是 WHERE 条件让右表过滤后更小，优化器“自作聪明”选了它当驱动表
-
join_buffer_size只在被驱动表无法走索引（type=ALL或type=index）时才起作用；开大只是掩盖问题，不能根治 - 优先解决索引和 WHERE 下推，而不是调大
join_buffer_size；否则容易挤占其他连接内存，引发 OOM
临时表和分阶段 JOIN 哪种更适合线上
临时表更可控，尤其适合中间结果集小、过滤强、且后续 JOIN 频繁的场景；分阶段 JOIN 更适合应用层有并发处理能力、能接受多次网络往返的系统。
- 用
CREATE TEMPORARY TABLE ... SELECT把核心过滤后的数据拎出来，再对临时表建索引（如INDEX (user_id)） - 临时表只在当前会话存在，不用手动删，但要注意磁盘空间监控（特别是
tmpdir） - 避免在事务中创建大量临时表，否则可能触发
innodb_temp_data_file_path扩容抖动 - 如果业务允许，物化快照（如每天凌晨跑
CREATE TABLE order_snapshot AS SELECT ...）比实时 JOIN 稳定得多
真正卡住性能的，从来不是 JOIN 语法怎么写，而是你有没有盯着 EXPLAIN 里的 key 和 rows 看，有没有去 SHOW CREATE TABLE 核对字段类型，以及有没有意识到 optimizer_search_depth 正在偷偷吃掉你的 CPU——这些地方一漏，其他所有操作都像给漏水的桶刷漆。
