MySQL优化器忽略gender等低区分度索引是因成本估算后认为全表扫描更快，核心在于Handler_read_key与Handler_read_rnd_next引发的随机I/O开销远超顺序扫描；区分度低于0.01时基本无效，需用COUNT(DISTINCT)/COUNT(*)精确计算。
MySQL优化器为什么常 ignore gender 这类索引
不是它“不支持”，而是它算过账后主动放弃——走索引比全表扫描还慢。核心开销在两处：Handler_read_key（读索引页）+ Handler_read_rnd_next（回表取行），而低区分度列命中后要访问大量主键，随机 I/O 成本远超顺序扫描。比如 is_deleted = 0 匹配 99.5% 的行，优化器一看：扫一半索引叶子节点，再随机跳着读 99.5% 的主键页？不如直接顺序扫一遍表。
验证很简单：EXPLAIN SELECT * FROM user WHERE gender = 'male'; 如果 type 是 ALL，key 是 NULL，说明已被忽略。这不是 bug，是成本估算后的理性选择。
区分度怎么算？低于多少就该警惕
别信 SHOW INDEX 里的 Cardinality，那是采样估算值（默认只看 8 个页），误差大、更新滞后。真正该跑的是：
SELECT COUNT(DISTINCT gender) / COUNT(*) AS selectivity FROM user;
结果低于 0.01（即 1%）基本可判为低区分度；0.2 左右属于“勉强可用但效果有限”；高于 0.9 才算高价值索引候选。注意：状态字段如 status 若 90% 是 'processing'，那它的区分度就是 0.2，单列建索引意义不大。
常见误判点：
- 把
COUNT(*)当成总行数，实际应查TABLE_ROWS（来自INFORMATION_SCHEMA.TABLES），但它是采样估计值，仍不如上面 SQL 精确 - 用
ANALYZE TABLE后立刻看Cardinality，却没等innodb_stats_auto_recalc生效或手动触发直方图更新
status 字段单独建索引后反而变慢的三个原因
写入性能下降、查询被跳过、联合索引失效风险，三者常同时发生：
- 每次
UPDATE或INSERT都要维护该索引页，而低基数列索引页分裂频繁、缓存命中率低 - 若该字段又进了联合索引但放错了位置（比如
KEY idx_status_user_id (status, user_id)），那WHERE user_id = ?就完全用不上这个索引——最左前缀失效 - 即使
WHERE status = 'done' AND create_time > '2026-01-01'这种查询，如果status在联合索引里排第一，优化器仍可能因 selectivity 太低而弃用整个索引
真正有效的做法是换顺序：KEY idx_user_id_status (user_id, status)，让高区分度列打头阵。
真要加速低区分度字段查询，优先试试这些替代方案
硬建单列索引是下策。更务实的解法取决于你的查询模式和数据分布：
- 高频等值 + 极小结果集（如
is_deleted = 1只有 0.1% 行）→ 可建，但必须EXPLAIN验证rows是否显著下降 - 只查索引字段（
SELECT is_deleted FROM user WHERE is_deleted = 0）→ 走type: index，避免回表，能接受 - 配合表达式索引（MySQL 5.7+）：
ALTER TABLE order ADD COLUMN is_overdue BOOLEAN AS (due_date - 分区表（LIST/RANGE）冷热分离：
CREATE TABLE log PARTITION BY LIST COLUMNS(status) (...)，让WHERE status = 'archived'只扫一个分区 - 开启持久化统计 + 直方图（MySQL 8.0+）：
ANALYZE TABLE t UPDATE HISTOGRAM ON status;，帮优化器看清值频次分布
最容易被忽略的是：线上加索引可能锁表（尤其大表），而低区分度字段一旦进了联合索引又极易因顺序错误导致整条索引失效——验证顺序、压测效果、观察 Handler_read_rnd_next 变化，这三步跳不得。
