Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > MySQL联合索引字段顺序、区分度与优化器

MySQL联合索引设计中字段顺序、区分度与优化器行为示例详解

作者：代码怪兽大大作战

索引设计是数据库优化中的关键环节,遵循三大黄金原则可显著提升查询性能,这篇文章主要介绍了MySQL联合索引设计中字段顺序、区分度与优化器行为的相关资料,文中通过示例代码介绍的非常详细,需要的朋友可以参考下,

在日常开发中，我们常常为查询加上联合索引，例如：

CREATE INDEX idx_unit_user ON t_user (unit_id, user_id);

但在很多项目里，还能看到这种写法：

CREATE INDEX idx_del_unit_user ON t_user (del_flag, unit_id, user_id);

del_flag 表示是否删除，只有 0 和 1 两种取值。

很多人认为“查询总有 del_flag=0 条件，索引当然要从它开始”，

但事实上，这样反而可能拖慢查询速度。

本文将系统讲清楚三个关键问题：

  1. 联合索引字段顺序的重要性

  2. 区分度（Cardinality）对索引效率的影响

  3. MySQL 优化器是否会自动调整 WHERE 条件顺序

一、联合索引的匹配原理回顾

联合索引 (a, b, c) 的底层是一个 B+Tree。

MySQL 检索时会按照索引定义的列顺序有序排列：

a → b → c

因此，它遵循 最左前缀原则（Leftmost Prefix Rule）：

这意味着：索引列的顺序决定了 MySQL 能否利用该索引。

二、区分度（Cardinality）是什么？

区分度是衡量字段“区分能力”的指标：

区分度 = 不同值数量 / 总记录数

可通过命令查看：

SHOW INDEX FROM your_table;

其中 Cardinality 表示索引中不同值的大致数量。

字段取值示例区分度是否适合放在索引前面
del_flag0/1极低❌
genderM/F极低❌
unit_id上千单位中高✅
user_id唯一极高✅

三、为什么低区分度字段放前面会拖慢查询？

假设你定义了：

CREATE INDEX idx_del_unit_user ON t_user (del_flag, unit_id, user_id);

del_flag 只有两种值（0、1）。

查询如下：

SELECT * FROM t_user WHERE del_flag = 0 AND unit_id = 1001;

索引的逻辑结构类似：

(del_flag=0) → [unit_id 排序 ...]

(del_flag=1) → [unit_id 排序 ...]

MySQL 实际上会扫描整个 (del_flag=0) 这半边索引树，

再在其中过滤出 unit_id=1001 的数据。

因为 del_flag 不能有效缩小数据范围，性能几乎无提升。

低区分度列放在前面时，索引分区极不均衡，效果有限。

四、优化设计：高区分度字段放前

如果查询模式是：

WHERE del_flag=0 AND unit_id=? AND user_id=?

更合理的索引应为：

CREATE INDEX idx_unit_user_del ON t_user (unit_id, user_id, del_flag);

执行顺序如下：

  1. MySQL 先根据 unit_id 定位；

  2. 再通过 user_id 精确匹配；

  3. 最后判断 del_flag=0。

结果是：扫描范围更小，性能显著提升。

五、WHERE 条件顺序会影响吗？

很多人问：

“如果我写的 SQL 是 WHERE del_flag=0 AND unit_id=? AND user_id=?，
那是不是应该把 unit_id 放前面？”

答案是：不用。

MySQL 优化器会自动调整逻辑顺序

MySQL 的优化器会：

换句话说：

实测验证

索引：

CREATE INDEX idx_unit_user_del ON t_user (unit_id, user_id, del_flag);

两条 SQL：

EXPLAIN SELECT * FROM t_user 
WHERE del_flag=0 AND unit_id=1001 AND user_id=8888;

EXPLAIN SELECT * FROM t_user 
WHERE unit_id=1001 AND user_id=8888 AND del_flag=0;

结果完全一致：

key: idx_unit_user_del
key_len: ...
rows: 1
Extra: Using index condition

✅ 说明优化器自动识别了最优执行路径，
WHERE 条件顺序无关紧要。

但优化器不会“反转索引”

如果索引定义是：

CREATE INDEX idx_del_unit_user ON t_user (del_flag, unit_id, user_id);

那无论你写：

WHERE unit_id=1001 AND user_id=8888 AND del_flag=0;

还是反过来写，

优化器都无法跳过 del_flag 直接用 (unit_id, user_id)。

只能从 del_flag=0 那个分支扫描，性能依然很差。

六、实战对比

查询索引是否命中说明
WHERE unit_id=? AND user_id=? AND del_flag=0(unit_id, user_id, del_flag)✅ 完整命中🚀 性能最优
WHERE del_flag=0 AND unit_id=? AND user_id=?(unit_id, user_id, del_flag)✅ 完整命中🚀 一样快
WHERE del_flag=0 AND unit_id=?(unit_id, user_id, del_flag)✅ 部分命中👍 仍快
WHERE del_flag=0(unit_id, user_id, del_flag)❌ 不命中最左前缀🐢 慢
WHERE unit_id=? AND user_id=?(del_flag, unit_id, user_id)❌ 无法跳过 del_flag🐢 慢

七、区分度与索引顺序的设计原则

原则说明
区分度优先高区分度列放在前（如 unit_id、user_id）
过滤性优先查询中最能减少扫描范围的条件放前
稳定性优先每次查询必带的条件（如 del_flag）放最后
低区分度列不单独建索引例如 0/1、状态、布尔值
用 EXPLAIN 验证执行计划理论与实际可能受统计信息影响

八、推荐实践模板

查询场景推荐索引
WHERE del_flag=0 AND unit_id=?(unit_id, del_flag)
WHERE del_flag=0 AND user_id=?(user_id, del_flag)
WHERE del_flag=0 AND unit_id=? AND user_id=?(unit_id, user_id, del_flag)

🚫 不推荐 (del_flag, unit_id, user_id)
✅ 推荐 (unit_id, user_id, del_flag)

九、总结

重点说明
✅ 索引顺序决定可用性最左前缀原则
✅ 区分度决定效率区分度高 → 放前面
✅ WHERE 条件顺序无关紧要优化器会自动重排
❌ 低区分度列放前浪费索引如 del_flag、status
✅ 正确索引能提升数十倍性能用 EXPLAIN 验证

💬 一句话总结：

MySQL 会自动优化 WHERE 条件顺序，但不会改变索引定义顺序。
因此，请始终把高区分度字段放在联合索引前列，
把低区分度的 del_flag、status 等放在最后。

到此这篇关于MySQL联合索引设计中字段顺序、区分度与优化器行为的文章就介绍到这了,更多相关MySQL联合索引字段顺序、区分度与优化器内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文