索引区分度决定索引价值，计算公式为唯一值个数÷总行数；≥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。
