17370845950

连接字段无索引会导致JOIN性能骤降十倍以上，需为ON/WHERE中的等值连接字段建索引；LEFT JOIN右表、INNER JOIN被驱动表的连接字段必须有索引；复合条件需按ON顺序建联合索引；务必用EXPLAIN验证type（ref/eq_ref）、key（非NULL）及Extra（无Using join buffer）。

连接字段上没索引，查询直接变慢十倍以上

MySQL 在执行 JOIN 时，如果连接条件（如 ON t1.id = t2.t1_id）涉及的字段没有索引，优化器大概率会走嵌套循环（Nested Loop），对右表做全表扫描。尤其当右表有几十万行，而左表只返回几百行，性能损耗非常明显。

关键判断点：连接字段是否在 WHERE 或 ON 中作为等值条件出现。只要出现，就该优先考虑加索引。

• 左连接（LEFT JOIN）中，右表的连接字段必须有索引（如 t2.t1_id）
• 内连接（INNER JOIN）中，两张表的连接字段都建议有索引，但优化器通常选更小/过滤性更强的那张表作驱动表，所以被驱动表的连接字段索引更重要
• 复合连接（如 ON a.x = b.x AND a.y = b.y）需要联合索引，顺序按 ON 中出现顺序来（(x, y)），不能只建单列索引

EXPLAIN 结果里看 type 和 key 才算数

别光看 SQL 写得“顺”，一定要用 EXPLAIN 验证实际走没走索引。重点关注两列：

• type：值为 ref、eq_ref、range 表示走了索引；ALL 或 index 就是全表或全索引扫描，危险信号
• key：显示实际使用的索引名。如果是 NULL，说明没走索引（哪怕你建了，也可能因隐式类型转换、函数包裹等原因失效）
• 注意 Extra 列：出现 Using join buffer (Block Nested Loop) 是没走索引的典型表现；Using index 是好事，说明覆盖索引生效

EXPLAIN SELECT u.name, o.amount 
FROM users u 
JOIN orders o ON u.id = o.user_id 
WHERE u.status = 'active';

连接 + 过滤混合场景，联合索引要包含所有驱动条件

真实业务里，连接往往和过滤共存。比如查「某个城市活跃用户的最近订单」，SQL 类似：

SELECT u.name, o.created_at 
FROM users u 
JOIN orders o ON u.id = o.user_id 
WHERE u.city = 'shanghai' AND u.status = 'active';

这时只给 users.city 加单列索引不够——因为 u.id 还要用于连接 orders。最优解是建联合索引：

• ALTER TABLE users ADD INDEX idx_city_status_id (city, status, id);
• 顺序不能乱：WHERE 中的等值条件放前（city, status），最后放连接字段（id），这样既能快速定位用户，又能直接用 id 去关联订单表，避免回表
• 如果 orders 表的 user_id 没索引，这个联合索引再好也没用——右表连接字段索引仍是刚需

多表 JOIN 时，索引选择受驱动表顺序影响

MySQL 5.7+ 默认启用 join_cache_level 和基于成本的优化器，但驱动表顺序仍可能被强制指定（如加 STRAIGHT_JOIN）。这意味着：

• 如果你用 STRAIGHT_JOIN 强制 users 驱动 orders，那么 orders.user_id 的索引质量决定整体性能上限
• 反之，若优化器选 orders 作驱动表（比如它加了 WHERE order_date > '2025-01-01'），那 users.id 的索引就更重要
• 复杂 JOIN 链（A→B→C）中，中间表 B 的连接字段（如 B.a_id 和 B.c_id）要分别建索引，不能指望一个索引同时服务两个方向

最常被忽略的一点：字符集不一致导致索引失效。比如 users.name 是 utf8mb4，logs.user_name 是 utf8，即使都建了索引，ON users.name = logs.user_name 也会触发隐式转换，让索引失效。检查 SHOW CREATE TABLE 确认两边字符集和排序规则完全一致。