超过10秒的JOIN查询已触发MySQL慢查询阈值，主因是中间结果集爆炸或索引失效；需立即用EXPLAIN检查rows、type、filtered三列，重点规避LEFT JOIN中WHERE误用、隐式转换、NULL陷阱及多表JOIN膨胀问题。
超过10秒的JOIN查询不是“有点慢”，而是已经触发MySQL默认慢查询阈值，说明执行路径严重失控——大概率是中间结果集爆炸或索引完全未生效。
EXPLAIN里rows暴增就是JOIN失控的明确信号
别等SQL跑完再看耗时，写完就该跑EXPLAIN。重点盯三列：rows、type、filtered。
-
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陷阱要警惕：LEFT JOIN右表字段参与WHERE时，
WHERE b.col IS NOT NULL会让左连接退化为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 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）一般不放临时表——它是驱动源，提前过度过滤反而丢失关联上下文
索引不是建了就生效，得看实际使用路径
外键约束不自动建索引，orders.user_id哪怕已是外键，也必须手动建索引。
- 复合索引要覆盖JOIN + WHERE：比如
WHERE u.status = 'active' AND u.city = 'shanghai'，建INDEX(status, city, id)，id放最后用于回表 - 避免函数操作：用
created_at >= '2026-06-01'，别写DATE(created_at) = '2026-06-01' - 统计信息过期会导致优化器选错索引，必要时执行
ANALYZE TABLE orders
真正卡住的往往不是语法或逻辑，而是中间结果集膨胀后引发的磁盘IO和内存溢出——EXPLAIN里的rows值，比最终返回行数更能暴露问题本质。
