mysql在多表连接时如何选择合适的索引

来源：这里教程网时间：2026-02-28 20:39:13 作者：

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

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 > '2024-01-01'
），那
users.id
的索引就更重要复杂 JOIN 链（A→B→C）中，中间表 B 的连接字段（如
B.a_id
和
B.c_id
）要分别建索引，不能指望一个索引同时服务两个方向

最常被忽略的一点：字符集不一致导致索引失效。比如