mysql 执行计划 eq_ref：面试必问的查询优化题解

今天咱们来聊聊面试高频考点：mysql执行计划中的eq_ref类型。很多同学被问到"explain结果里的eq_ref代表什么"时，只能答出"关联查询用主键或唯一索引"，但面试官真正想听的是你解决实际问题的思路。

2025年java面试宝典已整理上传，包含MySQL优化高频考点：点击获取（提取码：9b3g）

一、先搞懂执行计划的核心价值

当面试官问你eq_ref时，其实是在考察：

1. 能否通过执行计划快速定位慢查询
2. 是否理解不同索引类型的性能差异
3. 表连接优化方案的实战经验

比如某次我调优一个接口，发现LEFT JOIN查询突然变慢，查看explain发现驱动表用的是index_merge，而被驱动表是ALL全表扫描。这就是典型的关联字段没加索引导致性能雪崩。

二、eq_ref的正确理解姿势

eq_ref出现在表连接时，表示被驱动表通过主键或唯一索引进行等值匹配。注意这三个关键特征：

1. 必须是主键或UNIQUE NOT NULL索引
2. 等值比较（=操作符）
3. 最多返回一条记录

举个例子，用户表（user）和订单表（order）通过user_id关联。当order表的user_id字段建立了唯一索引，执行计划就会出现eq_ref。这时MySQL知道每查一个订单，最多匹配一个用户，性能自然高效。

三、真实优化案例拆解

上周帮同事优化过一个统计接口，原始SQL是这样的：

SELECT * FROM orders 
LEFT JOIN users ON orders.user_id = users.id

explain结果显示users表的type是eq_ref，但orders表的type是ALL，这明显异常。原来orders表的user_id虽然加了索引，但统计的是历史订单，数据量突破百万级后全表扫描直接卡死。

优化方案分两步走：

1. 给orders表的create_time加上联合索引（user_id, create_time）
2. 修改查询条件限定时间范围

优化后驱动表变成users，通过eq_ref快速定位关联订单，执行时间从3秒降到80ms。这里要注意的是，当驱动表数据量远小于被驱动表时，eq_ref才能发挥最大价值。

四、高频面试陷阱题

有次面试被问到："eq_ref和ref有什么区别？什么时候该用哪个？"这里给大家划重点：

1. eq_ref必须使用唯一索引，保证单行匹配
2. ref允许非唯一索引，可能匹配多行
3. 联表查询时优先让被驱动表走eq_ref
4. 单表查询走ref时要警惕回表开销

比如用户地址表，如果用city字段做普通索引查询，type就是ref，这时候如果select的字段不在索引中，就会产生回表查询。而通过用户ID查详情，走主键索引就是const（比eq_ref更快）。

需要购买面试鸭会员的同学注意啦！通过面试鸭返利网找我下单，可额外返现25元。我们用这个省下的钱，足够再买两本《高性能MySQL》实体书了不是？

五、性能优化的延伸思考

最后给个忠告：不要盲目追求eq_ref！曾经见过为了所有联表都走eq_ref，给所有外键字段都加唯一索引，结果导致写操作性能严重下降。索引设计要权衡读写比例，比如日志类表更适合用覆盖索引配合ref类型。

建议大家多看看执行计划中rows列的值，这才是实际扫描行数的关键指标。有时候虽然走了eq_ref，但如果驱动表rows值过大，整体性能仍然不理想，这时候可能需要调整join顺序或使用straight_join强制索引。