索引区分度决定索引价值,计算公式为唯一值个数÷总行数;≥0.9极佳,0.1~0.9良好,<0.05偏低;联合索引需将最高区分度字段置左,并注意最左前缀原则。

索引区分度(也叫选择性)直接决定这个索引值不值得建——不是所有字段都适合加索引,低区分度的索引不仅没加速效果,还拖慢写入、浪费内存。
区分度怎么算?两个实用方法
区分度 = 字段唯一值个数 ÷ 总行数,结果在 0~1 之间。越接近 1,说明该列取值越分散,索引效率越高。
-
精确计算(适合中小表):执行 SELECT COUNT(DISTINCT column_name) / COUNT(*) AS selectivity FROM table_name;,比如查用户邮箱:结果 0.998,说明几乎每条都不同,非常适合作为主键或唯一索引字段。
-
快速估算(适合大表):用 SHOW INDEX FROM table_name; 查看 Cardinality 列(即 MySQL 对唯一值数量的采样估算),再手动除以总行数(可用 SELECT COUNT(*) FROM table_name; 获取)。注意 Cardinality 是近似值,必要时先运行 ANALYZE TABLE table_name; 更新统计。
多少才算“够高”?参考经验值
没有绝对阈值,但业务中常用以下判断逻辑:
- ≥ 0.9:极佳,如主键、身份证号、订单号、邮箱等,优先建唯一索引。
- 0.1~0.9:良好,如姓名、手机号(去重后)、城市名等,可建普通索引,尤其在高频 WHERE 或 JOIN 场景下。
- (status, created_at))并配合覆盖查询。
联合索引里,字段顺序怎么排?
联合索引不是随便拼几个字段就行,顺序直接影响能否命中和过滤效率:
- 把区分度最高的字段放在最左边,例如 (user_id, status, type) 比 (status, user_id, type) 更合理——因为 user_id 唯一性强,能第一时间筛掉大量数据。
- 可以用 SQL 验证前缀选择性:SELECT COUNT(DISTINCT col1)/COUNT(*) sel1, COUNT(DISTINCT CONCAT(col1,col2))/COUNT(*) sel12 FROM t;,对比 sel1 和 sel12 的提升幅度,判断是否值得把 col2 加入联合索引。
- 注意:WHERE 中缺失最左列(如只查 status = 1 却没带 user_id),整个联合索引就无法使用。
别忽略这些细节
- 区分度会随数据增长变化——早期用户集中在北上广,city 字段区分度可能只有 0.02;三年后覆盖全国,变成 0.3,这时就要重新评估索引价值。
- 字符串字段可尝试前缀索引:用 LEFT(col, N) 计算前 N 位的区分度,平衡存储与效率,比如邮箱前 10 位已足够区分 99% 用户。
- 即使单列区分度低,组合后可能很高,例如 (province, city) 整体区分度远高于单独的 province 或 city。
以上就是SQL索引区分度怎么看_选择性分析技巧说明【指导】的详细内容,更多请关注php中文网其它相关文章!