索引选择性低会导致全表扫描
当
WHERE条件列的选择性很低（比如性别字段只有
'男'/
'女'两种值），MySQL 优化器很可能放弃使用该索引，直接走全表扫描。因为回表或扫描索引本身开销可能比遍历整张表还大。 选择性 =
COUNT(DISTINCT column) / COUNT(*)，越接近 1 越好（如用户邮箱） 低于 0.05～0.1 时，B+ 树索引通常失效（具体阈值受数据量、行大小、存储引擎影响） 用
EXPLAIN查看
type字段：若为
ALL或
index，说明没走有效索引
联合索引的最左前缀原则直接影响选择性判断
MySQL 只能利用联合索引的连续前缀部分。即使
(a, b, c)中
a选择性差，但
(a, b)组合选择性高，查询
WHERE a = ? AND b = ?仍可高效命中索引。 避免把低选择性字段放在联合索引最左侧（如
(status, user_id)中
status只有 3 个值） 高频等值查询字段优先靠左；范围查询（
>,
BETWEEN）字段必须放最右，否则右侧字段无法被索引使用 用
SHOW INDEX FROM table_name确认索引定义顺序，别只看
CREATE INDEX语句写法
NULL 值会破坏索引选择性统计准确性
MySQL 的
ANALYZE TABLE在统计列基数（
Cardinality）时，对含大量
NULL的列可能严重低估实际区分度，导致优化器误判索引价值。 执行
SELECT COUNT(*), COUNT(column), COUNT(DISTINCT column) FROM table对比真实选择性 若列允许
NULL且占比高，考虑改用默认值（如
'unknown'）替代，或在查询中显式排除：
WHERE column IS NOT NULL AND column = ?
innodb_stats_persistent = ON+ 定期
ANALYZE TABLE可缓解统计偏差，但无法根治
NULL干扰
覆盖索引能绕过选择性瓶颈提升效率
即使筛选字段选择性低，只要查询所需所有字段都在索引中（即覆盖索引），MySQL 就无需回表，此时哪怕走
index类型扫描，性能也远好于全表扫描。 例如表有
(status, create_time, id)联合索引，查询
SELECT id FROM t WHERE status = 'draft'就是覆盖扫描 注意
SELECT *几乎不可能被覆盖，务必明确列出需要的字段 用
EXPLAIN检查
Extra列是否含
Using index，这是覆盖索引生效的关键标志
EXPLAIN SELECT id, create_time FROM orders WHERE status = 'shipped';索引选择性不是独立指标，它和查询模式、字段顺序、NULL 分布、是否覆盖紧密耦合。单独优化某列的选择性没意义，得结合
EXPLAIN输出和实际慢查询场景一起看。
