超过10秒的join查询已触发mysql慢查询阈值，主因是中间结果集爆炸或索引失效；需紧盯explain的rows、type、filtered三列，严防left join中where误写、隐式转换、null陷阱及多表join条件缺失，并优先用临时表与覆盖索引优化。
超过10秒的JOIN查询不是“有点慢”，而是已触发MySQL默认慢查询阈值，说明执行路径严重失控——大概率是中间结果集爆炸或索引完全未生效。
EXPLAIN必须盯死rows、type、filtered三列
别等SQL跑完再看耗时，写完就该跑EXPLAIN。这三列是判断JOIN是否失控的核心信号：
-
rows从几千跳到百万级？说明某次JOIN后结果集失控，比如ON a.id = b.a_id漏写了a.dt = b.dt，数据量可能翻N倍 -
type出现ALL或index？对应表没走索引，常见原因是JOIN字段缺失索引，或类型不一致（如VARCHAR(20)vsVARCHAR(50)） -
filtered低于5%？意味着95%以上行被WHERE干掉——这部分条件本该下推到ON里，而不是留在最后过滤
LEFT JOIN右边表的WHERE条件必须挪进ON
这是最常踩的坑：把WHERE b.status = 'active'写在最后，MySQL会先全量JOIN再过滤；改成ON a.id = b.a_id AND b.status = 'active'，就能让优化器提前剪枝。
-
隐式转换也致命：比如
ON UPPER(a.name) = UPPER(b.name)，索引直接失效 -
NULL陷阱要警惕：WHERE b.col IS NOT NULL会让LEFT JOIN退化为INNER JOIN - 复合JOIN必须字段对齐：
JOIN t3 ON t1.b = t3.b AND t1.dt = t3.dt，少一个条件，行数可能指数增长
超5张表JOIN别硬拼一条SQL
硬写10表JOIN，MySQL大概率用Nested Loop，复杂度O(M×N)，两百万行×一百万行=两万亿次比较——CPU满载也跑不完。
- 优先用
CREATE TEMPORARY TABLE缓存中间结果，只保留真正要用的字段，例如：CREATE TEMPORARY TABLE temp_orders AS SELECT id, user_id, status FROM orders WHERE created_at > '2026-06-01' - 索引必须按JOIN顺序建：如果
JOIN temp_orders ON users.id = temp_orders.user_id，那就建INDEX(user_id, status)，别倒过来 - 主表（如
orders）一般不放临时表——它是驱动源，提前过度过滤反而丢失关联上下文
覆盖索引必须覆盖JOIN + WHERE + SELECT字段
覆盖索引能直接跳过回表，因其将SELECT所需字段全部包含在索引中，使MySQL仅通过索引B+树即可返回结果，无需再回主键树查找整行数据。
- 例如常写：
SELECT user_id, order_time FROM orders JOIN users ON orders.user_id = users.id WHERE users.status = 'active'，那就该建两个索引：idx_users_status_id（status,id）和idx_orders_user_time（user_id,order_time） -
EXPLAIN输出中看到type=ref且Extra含Using index，才算真正命中覆盖索引 - 别把
TEXT、BLOB字段塞进索引，它们不支持索引存储
真正卡住性能的往往不是JOIN本身，而是中间结果集膨胀后引发的随机IO、内存溢出或临时磁盘表；而这些，在EXPLAIN里rows暴增和Extra出现Using temporary或Using filesort时就已暴露无遗。
