索引选择性是衡量索引过滤效率的核心指标，计算为COUNT(DISTINCT column)/COUNT(*)，≥0.1为良好，0.01~0.1需结合查询判断，
索引选择性（Selectivity）是衡量索引过滤效率的核心指标，本质是“索引列值越唯一，查询越快”。高选择性意味着该列能大幅缩小扫描范围；低选择性（如性别、状态字段）则可能让优化器放弃使用索引，甚至引发全表扫描。
选择性计算公式与阈值参考
选择性 = 去重值数量（COUNT(DISTINCT column)） / 总行数（COUNT(*)）。结果介于 0 到 1 之间：
- ≥ 0.1（10%）：通常视为良好选择性，索引较有价值
- 0.01 ~ 0.1：中等选择性，需结合查询模式判断（如常用于 WHERE + ORDER BY 组合）
避免常见误判：NULL 和重复分布的影响
直接套用公式可能失真，需关注数据实际分布：
- 大量 NULL 值会拉低 DISTINCT 计数，但多数数据库对 NULL 索引处理特殊（如 B-Tree 默认不存 NULL），应单独统计非 NULL 行占比
- 看似高选择性，但热点值（如 status=‘active’ 占 95%）会导致索引在多数查询中失效——建议用直方图或采样检查值频次分布
- 时间类字段（如 create_time）整体选择性高，但按“最近7天”查询时有效选择性骤降，需结合业务时间窗口评估
组合索引的选择性评估策略
组合索引（A, B, C）不是简单叠加，而是按最左前缀逐级收敛：
- 先算 A 的选择性；若不足，再看 A+B 的联合去重率（COUNT(DISTINCT A, B)/COUNT(*)）
- 真正有效的组合索引，往往要求前导列（A）有中等以上选择性，且后缀列（B/C）能在前导列基础上显著提升过滤能力
- 用 EXPLAIN 验证：对比单列索引与组合索引的 key_len 和 rows，rows 显著减少才说明组合生效
实战建议：从查询驱动反推索引价值
脱离 WHERE 条件谈选择性没有意义。推荐三步法：
- 抓取慢查询日志，提取高频 WHERE、JOIN、ORDER BY 涉及的列
- 对这些列分别执行选择性计算，并按查询谓词（=、IN、BETWEEN、LIKE 'abc%'）分类验证有效性
- 用 FORCE INDEX 或索引提示临时启用索引，观察执行计划中的 type（最好为 ref/const）、rows、Extra（避免 Using filesort/Using temporary）
