低区分度字段（如gender）单独建索引无效，因回表开销大、选择性低，优化器会主动放弃；联合索引中应将高区分度字段放前面，避免索引失效；切勿将其设为聚集索引。
低区分度字段索引导致回表开销翻倍
性别字段只有“男”“女”两个值，100万行数据中每个性别约50万条。建了idx_gender后，MySQL仍需从B+树索引页里逐条读出50万个主键，再逐一回表查真实数据行——相当于做50万次随机IO。而全表扫描是顺序IO，一次磁盘预读就能拉取多行，实际耗时反而更低。
常见错误现象：EXPLAIN显示type为index（走索引但扫全索引），rows接近总行数，Extra里没有Using index（说明没覆盖索引）。
- 区分度低于1%的字段（如
gender、status、is_deleted）单独建索引基本无效 - 用
SHOW STATUS LIKE 'Handler_read%'观察：若Handler_read_key高但Handler_read_rnd也高，说明大量回表 - InnoDB里非聚集索引必须回表，这是硬性开销，无法绕过
优化器主动放弃低区分度索引
MySQL 5.7+的优化器会估算索引选择性，发现gender = '男'要返回50%行时，直接跳过索引走ALL（全表扫描）。你看到EXPLAIN里key列为NULL，不是没建索引，而是它判断“用了更慢”。
验证方式：强制使用索引看效果是否更差
SELECT * FROM users USE INDEX (idx_gender) WHERE gender = '男';
你会发现执行时间明显长于不加USE INDEX的版本。
- 计算选择性：执行
SELECT COUNT(DISTINCT gender) / COUNT(*) FROM users;，结果0.000002就该删掉这个单列索引 - 8.0之后优化器更激进，低选择性索引被忽略的概率更高
-
optimizer_switch里use_index_extensions=on等设置会影响判断，但改配置不如删索引来得干脆
联合索引里低区分度字段放前面会废掉整个索引
如果建了KEY idx_gender_time (gender, create_time)，但查询只用WHERE gender = '男'，那create_time根本用不上——最左前缀失效。此时索引退化成纯gender索引，问题照旧。
正确做法是把高区分度字段放前面：
- 想查“男性用户最近注册的10条”，应建
KEY idx_time_gender (create_time, gender) - 如果业务常查
WHERE gender = '男' AND age BETWEEN 25 AND 30，优先考虑(age, gender)而非反过来 - 联合索引字段顺序必须按查询条件中高频、高选择性的列优先排列
聚集索引不能随便让给低区分度字段
有人提议把gender设为聚集索引（即主键），认为“数据物理有序就能快”。这在理论上成立，但代价极大：所有二级索引的叶子节点都存这个聚集索引值，而gender只有两个值，会导致二级索引严重膨胀；且一旦业务需要按user_id或order_no范围查询，性能会断崖式下跌。
真正能承受聚集索引变更的场景极少，除非表本身只按该字段查询且无其他范围/排序需求。
- InnoDB默认用自增
id作聚集索引，这是经过权衡的通用解 - 把
gender当主键 → 所有二级索引变大近一倍（因索引项里存的是'男'或'女'字符串，而非紧凑整数） - 线上表修改聚集索引需重建整张表，锁表时间不可控，风险远高于删个普通索引
低区分度字段本身不是问题，问题在于把它当成独立加速手段。真正的优化点永远落在“查询模式”和“数据分布”的匹配上——索引是工具，不是护身符。
