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 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能