mysql如何处理索引基数过低情况_mysql索引选择性分析

根本原因是索引基数（cardinality）过低，导致优化器预估索引过滤效率差而弃用；可用 SHOW INDEX FROM table_name 查看 Cardinality 值，若远小于总行数（如性别字段仅2个值），则索引实际无效。为什么 EXPLAIN 显示用了索引但查询还是慢？根本原因常是索引基数（cardinality）太低——比如在性别字段建了索引，只有 'male' 和 'female' 两个值，MySQL 估算该索引过滤效率极差，优化器大概率会弃用它，甚至走全表扫描。这不是 bug，是成本估算的合理结果。用 SHOW INDEX FROM table_name 查看 Cardinality 列，若远小于表总行数（比如 基数不是实时更新的，ANALYZE TABLE 可触发重新采样，但对大表有锁开销，别频繁执行低基数字段单独建索引几乎没意义，除非搭配 WHERE + ORDER BY 或用于覆盖索引场景哪些字段容易踩“低基数索引”坑？典型陷阱集中在枚举类、状态位、布尔值、固定分类字段上，比如 status、is_deleted、type、gender。它们天然离散度差，索引选择性（selectivity）接近 0。判断选择性：用 SELECT COUNT(DISTINCT col) / COUNT(*) FROM table_name，结果 别迷信“加了索引就快”，MySQL 5.7+ 对低选择性索引更激进地跳过，8.0 还可能因直方图统计更准而进一步降低使用意愿如果必须按这类字段查，优先考虑组合索引：把低基数字段放在联合索引靠后位置，前面接高基数字段（如 (user_id, status)）如何让 MySQL “愿意用”低基数字段上的索引？强制使用（FORCE INDEX）只是掩耳盗铃，真正可行的是调整数据分布或访问模式。硬要让它用，得满足两个条件之一：索引能覆盖查询，或者 WHERE 条件本身足够稀疏（比如 status = 'processing' 实际只占 0.001% 行）。 稿定AI 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能