SQL索引选择性如何评估_字段基数分析方法【指导】

索引选择性越高查询效率通常越好，核心是字段基数（不同值数量/总行数），比值越接近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 '2025-01-01' AND '2025-01-07'），B+树索引仍高效；而如果只查 YEAR(create_time) = 2025，函数导致索引失效，再高基数也无用
• 复合索引中字段顺序影响选择性发挥：高选择性字段应前置，以便更快过滤

警惕数据倾斜与动态变化

基数不是静态指标，业务增长或数据清洗后可能大幅变动：

• 定期重采样：对核心表每月或每季度执行一次基数快照，对比趋势（如用户表的 phone 字段，初期测试数据重复多，上线后趋于唯一）
• 识别倾斜值：用 SELECT column_name, COUNT(*) FROM table GROUP BY column_name ORDER BY COUNT(*) DESC LIMIT 5 检查是否存在“超级重复值”，这类字段即使整体基数尚可，也可能让优化器放弃索引
• 分区表或分库场景下，需在各分片内分别评估，全局基数无意义