索引是否有效取决于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%'),后面的字段就失效了。 文小言 百度旗下新搜索智能助手,有问题,问小言。
相关推荐
wuminyu4 分钟前
JUC包的AQS与JVM的ObjectMonitor机制对比分析0566469 分钟前
RAG 向量检索:从“查字“到“查意“bug嘛我经常写11 分钟前
dbf文件UTF-8转GBK编码,以及两编码文件互转知行合一。。。14 分钟前
LangGraph--03--本地服务与 Studio 调试胡耀超15 分钟前
AI出事后,怎么查?——读《AI Forensics》梦想三三28 分钟前
Python从零实现AI Agent电商客服(Qwen/Ollama+SQLite源码解析)鹿鹿学长30 分钟前
国赛工业应用数学题:从31省规上工业数据到生产排程,四类高频赛题的破题打法你不是我我31 分钟前
【AI 测评】PostgreSQL主从流复制实战:数据同步、状态验证与故障切换月落归舟35 分钟前
Redis 三种消息队列实现方案笨鸟先飞,勤能补拙36 分钟前
密码学深度指南 — SecOps 工程师实战手册