mysql如何优化联合查询中的索引_mysql多表查询优化

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

联合查询中哪些字段必须加索引

联合查询（JOIN）性能差，90% 是因为驱动表和被驱动表的连接字段没索引，或者索引失效。MySQL 用

Nested Loop Join

，驱动表每行都要去被驱动表查匹配行——如果被驱动表的

ON

字段没索引，就会全表扫描。

必须加索引的字段包括：

JOIN
条件中的被驱动表字段（如
t2.user_id
）驱动表中用于过滤的字段（如
WHERE t1.status = 'active'
的
t1.status
）
ORDER BY
和
LIMIT
涉及的字段，若出现在最终结果集里且未被覆盖索引包含

注意：

ON

中多个字段要建联合索引，顺序按「驱动表过滤条件 → 被驱动表连接字段」排列，例如：

ALTER TABLE orders ADD INDEX idx_user_status (user_id, status);

EXPLAIN 看懂 JOIN 执行顺序是否合理

EXPLAIN

的

type

列是关键：

ALL

或

index

表示全表/全索引扫描，危险；

ref

、

eq_ref

、

const

才算走索引。同时看

rows

值——它反映 MySQL 预估的单次查找行数，不是总行数。

常见误判点：

驱动表选错了：
EXPLAIN
第一行是驱动表，但 MySQL 可能因统计信息不准选错。可用
STRAIGHT_JOIN
强制顺序
Extra
出现
Using join buffer (Block Nested Loop)
：说明被驱动表没走索引，正在回表硬扛
key
为
NULL
：该表完全没用上索引，哪怕你建了

示例：

EXPLAIN SELECT * FROM users u JOIN orders o ON u.id = o.user_id WHERE u.created_at > '2023-01-01';

—— 先确认

users

表是否走了

created_at

索引，再确认

orders

表是否走了

user_id

索引。

联合索引字段顺序怎么排才不浪费

联合索引不是字段堆砌，顺序直接影响能否命中。核心原则：**等值查询字段在前，范围查询字段在后，连接字段紧贴等值字段**。

比如三表关联：

users → orders → order_items

，常用条件是

u.status = 'active' AND o.created_at > '2024-01-01' AND oi.item_type = 'book'

，那么：

orders
表索引应为
(user_id, status, created_at)
：先用
user_id
匹配外键，再用
status
过滤，最后
created_at
做范围（不能放最前）
order_items
表索引应为
(order_id, item_type)
：
order_id
是连接字段，必须第一；
item_type
是等值过滤，放第二

反例：

(created_at, user_id)

对

WHERE created_at > ? AND user_id = ?

只能用上

created_at

，

user_id

失效。

小表驱动大表真的总是最优吗

“小表驱动大表”是经验法则，但 MySQL 8.0+ 的 CBO（基于成本优化器）会综合行数、索引选择性、IO 成本估算，不一定听你的。真正要干预的场景是：

统计信息过期：
ANALYZE TABLE
没跑过，导致优化器误判表大小 大表有高选择性索引，小表反而没索引：这时让大表当驱动表 + 走索引，比小表全表扫更优 使用
IN
子查询替代
JOIN
：有时
SELECT ... WHERE id IN (SELECT user_id FROM orders WHERE ...)
比
JOIN
更快，尤其子查询结果集小且有索引

验证方式：对比