索引选择性越高查询效率通常越好，核心是字段基数（不同值数量/总行数），比值越接近1越适合建索引；需结合查询模式、数据倾斜、动态变化等综合评估。
索引选择性越高，查询效率通常越好。评估的核心是看字段的基数（Cardinality）——即该字段不同值的数量与总行数的比值。比值越接近1，说明重复值越少，索引越有价值。
直接查看表统计信息
多数数据库提供内置命令快速获取字段基数估算：
-
MySQL：执行
SHOW INDEX FROM table_name，关注Cardinality列（注意这是估算值，需配合ANALYZE TABLE更新） -
PostgreSQL：查系统视图
pg_stats，如SELECT tablename, attname, n_distinct FROM pg_stats WHERE tablename = 'your_table' -
SQL Server：用
DBCC SHOW_STATISTICS('table', 'index_or_column')查看DistinctCount和密度（Density）
手动计算选择性比值
对关键字段做精确评估时，可运行 SQL 计算：
- 基础公式：
SELECT COUNT(DISTINCT column_name) * 1.0 / COUNT(*) FROM table_name - 若结果 > 0.95，适合建索引；0.1–0.95 视场景而定；状态码等低基数字段）
- 注意 NULL 值是否参与计数——
COUNT(DISTINCT column)默认忽略 NULL，如需包含，改用COUNT(DISTINCT COALESCE(column, 'NULL_VAL'))
结合查询模式验证实际收益
高基数不等于必须建索引，还要看 WHERE、JOIN、ORDER BY 中是否高频使用该字段：
- 用
EXPLAIN（MySQL/PostgreSQL）或EXECUTION PLAN（SQL Server）观察加索引前后是否走索引扫描、rows examined 是否显著下降 - 避免“伪高基数”陷阱：例如时间字段（如 create_time）基数极高，但若查询总是范围扫描（
BETWEEN '2024-01-01' AND '2024-01-07'），B+树索引仍高效；而如果只查YEAR(create_time) = 2024，函数导致索引失效，再高基数也无用 - 复合索引中字段顺序影响选择性发挥：高选择性字段应前置，以便更快过滤
警惕数据倾斜与动态变化
基数不是静态指标，业务增长或数据清洗后可能大幅变动：
- 定期重采样：对核心表每月或每季度执行一次基数快照，对比趋势（如用户表的 phone 字段，初期测试数据重复多，上线后趋于唯一）
- 识别倾斜值：用
SELECT column_name, COUNT(*) FROM table GROUP BY column_name ORDER BY COUNT(*) DESC LIMIT 5检查是否存在“超级重复值”，这类字段即使整体基数尚可，也可能让优化器放弃索引 - 分区表或分库场景下，需在各分片内分别评估，全局基数无意义
