索引是否有效取决于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%'),后面的字段就失效了。 文小言 百度旗下新搜索智能助手,有问题,问小言。
相关推荐
这个DBA有点耶31 分钟前
GROUP BY优化全解:如何写出既不丢数据又飞快的分组查询掉头发的王富贵4 小时前
【StarRocks】极限十分钟入门StarRocksNturmoils4 小时前
WHERE 条件别凭习惯写,常用查询先跑一遍荣码8 小时前
LangGraph多Agent协作:3个Agent干活比1个强,但我踩了4个坑用户8356290780511 天前
Python 操作 PDF 附件:添加、查看与管理指南Databend1 天前
在 AWS 中国峰会逛了一天,我在 Databend 展台看到了 Agent 数据基础设施的新思路宇宙之一粟1 天前
乐企版式文件生成平台学测绘的小杨2 天前
CompassFusion:一个从 GNSS 到 GNSS/INS 组合导航的独立工程包ClouGence2 天前
Oracle 数据同步为什么会出现数据不一致?长事务是常被忽略的原因zzzzzz3102 天前
当产品经理说这个很简单:我用Python自动化处理奇葩需求的实战指南