多表JOIN慢主因是优化器“盲选”执行路径，需先让驱动表过滤出小结果集、确保ON字段类型一致、为被驱动表单独建索引；5表以上应拆查询或设optimizer_search_depth=0。
多表 JOIN 慢，90% 不是 SQL 写得差，而是优化器在“盲选”执行路径——你得先让它看见小结果集，再让它用对索引，最后才轮到调参。
为什么 EXPLAIN 显示 type=ALL，但 ON 字段明明有索引？
这是最典型的“索引失效”假象。MySQL 不会为被驱动表使用索引，除非驱动表已经过滤出足够小的结果集，且 ON 字段类型、长度、NULL 属性完全一致。
-
SHOW CREATE TABLE必须逐字段比对：比如orders.user_id是INT UNSIGNED，而users.id是INT SIGNED，隐式转换直接让索引失效 -
EXPLAIN中key列为NULL、rows接近全表行数，说明索引根本没参与连接过程 - 联合索引不能靠“最左前缀”兜底：若
ON a.x = b.y，而b上只有INDEX (z, y)，那y不是首列，索引无效 - 被驱动表的 JOIN 字段必须单独建索引，哪怕它已是主键——因为 MySQL 优化器对主键的“走索引”判断有时过于保守
三张表以上 JOIN 就开始卡，是不是该换写法？
是。5 张表是硬分水岭：优化器搜索连接顺序的组合数从 24（4 表）暴增至 120（5 表）、720（6 表），CPU 花在“想怎么连”上，而不是“怎么执行”。这时执行计划质量已不可信。
- 优先拆成 2–3 个独立查询：第一步查核心主表（加
WHERE+LIMIT控制批次），第二步用IN批量查关联维表，第三步补扩展属性 - 避免在第二步中带入第一步未返回的字段做过滤（如
WHERE orders.created_at > '2026-09-01'），否则数据库可能被迫重连主表 - LEFT JOIN 链式嵌套极易触发全表扫描：若驱动表无强过滤条件，优化器可能把右表当驱动表，甚至悄悄转成 INNER JOIN
- 临时表方案更可控：
CREATE TEMPORARY TABLE tmp_orders AS SELECT id, user_id FROM orders WHERE ...，再对tmp_orders建INDEX (user_id)，后续 JOIN 就稳定得多
optimizer_search_depth=0 真的能救急吗？
能，而且见效最快。默认值 62 在 8+ 表 JOIN 时会让优化器陷入组合爆炸，设为 0 后 MySQL 改用动态剪枝策略，实际只评估最多 7 张表的连接顺序，编译耗时从秒级降到毫秒级，执行计划质量通常不降反升。
- 仅会话级生效：
SET optimizer_search_depth = 0，适合线上慢查询临时干预 - 全局修改需写入
my.cnf并重启，不适合审计或压测场景——执行计划可能随表数微调而变 - 这不是关优化器，而是逼它放弃穷举，转向启发式决策；配合
STRAIGHT_JOIN可进一步锁定连接顺序 - 别依赖它掩盖问题：如果
EXPLAIN显示Using temporary; Using filesort，说明逻辑层仍有冗余排序或聚合，得回溯 SQL 结构
“先过滤再 JOIN”到底该怎么写才不翻车？
关键在 WHERE 条件下推的位置和 LEFT JOIN 的语义陷阱。INNER JOIN 可以放心把条件写在 WHERE，但 LEFT JOIN 的过滤条件若误写在 WHERE，就会让右表 NULL 行被剔除，等效于 INNER JOIN。
- LEFT JOIN 的右表过滤必须写在
ON子句里，例如：LEFT JOIN users u ON o.user_id = u.id AND u.status = 'active'，而不是WHERE u.status = 'active' - 子查询裁剪要显式物化：
SELECT * FROM (SELECT id, user_id FROM orders WHERE created_at > '2026-09-01') o JOIN users u ON o.user_id = u.id，避免优化器将子查询“展开”回原始大表 - 函数导致索引失效是高频坑：
ON DATE(o.created_at) = '2026-09-29'会让created_at索引失效，应改用范围：o.created_at >= '2026-09-29' AND o.created_at - 别迷信
join_buffer_size：它只在被驱动表type=ALL时起作用，调大只是缓解症状，不是根治；优先解决索引和驱动表选择问题
真正难的不是知道该做什么，而是每次 EXPLAIN 出来后，你能快速判断哪一行是“驱动表失控”，哪一列是“索引被绕过”，哪一处 Extra 提示暴露了内存瓶颈。这些细节藏在每一行执行计划里，而不是文档标题下。
