索引是否有效取决于Cardinality值高低:接近总行数(≥95%)说明区分度高,适合建索引;<10%则单列索引意义不大;低区分度字段应置于联合索引后缀,如(created_at, status),并用EXPLAIN验证实际使用情况。索引有没有用,先看 Cardinality 值够不够高MySQL 的 SHOW INDEX FROM table_name 里那个 Cardinality 字段,不是"有多少行",而是"该列值大概有多少个不同取值"。它直接影响优化器是否愿意走索引。如果 Cardinality 只有几百,而表有百万行,那这个索引大概率被忽略------因为扫描索引再回表,比直接全表扫还慢。Cardinality 接近表总行数(比如 95% 以上),说明这列区分度高,适合建索引如果 Cardinality 小于总行数的 10%,基本可以判定:加单列索引意义不大注意:Cardinality 是采样估算值,执行 ANALYZE TABLE table_name 可刷新,但不会实时更新区分度低的字段硬加索引,反而拖慢写入比如 status 只有 'active'、'inactive'、'pending' 三个值,就算加上索引,查询时优化器大概率走全表扫描;更麻烦的是,每次 INSERT/UPDATE 都要维护这个索引 B+ 树,写放大明显。常见陷阱:给布尔型、枚举型、状态码字段单独建索引,却不结合查询条件中的其他过滤字段替代方案:把低区分度字段放在联合索引的**后缀位置**,比如 (created_at, status),靠前缀 created_at 拉高整体选择性验证方法:用 EXPLAIN 看 type 是否为 ref 或 range,而不是 ALL联合索引的顺序怎么排?看 WHERE 条件里的等值匹配和范围查询索引生效不只看有没有,更看字段在 WHERE 中的使用方式。MySQL 只能高效利用索引的最左前缀,一旦遇到范围查询(>、BETWEEN、LIKE 'abc%'),后面的字段就失效了。 文小言 百度旗下新搜索智能助手,有问题,问小言。
相关推荐
Elastic 中国社区官方博客6 小时前
搜索倍增器:推动收入、生产力和 AI 实现规模化青 春 记 忆6 小时前
Dify Docker Compose 通用无损升级指南:从备份、双版本预演到切换与回滚GlueNa2SiO36 小时前
03-Flask模板引擎Jinja2详解保定公民8 小时前
达梦数据库存储过程中的数组类型详解:基础数组与记录数组的差异化应用梦Arrebol8 小时前
Redis 内容及相关实验临沂GEO9 小时前
GEO搜索优化科普|正规地理位置流量运营入门指南大模型码小白9 小时前
Spring AI Tool 实现自然语言操作 MySQL 数据库详解Mr. zhihao10 小时前
死锁排查实战:JVM 唯一会“自动报案“的问题(场景 B5)荷蒲10 小时前
【小白量化Qbuddy】利用AI学习中文Python