连接字段无索引会导致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 或 O 
- 左连接（
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 确认两边字符集和排序规则完全一致。
