索引并非万能，对无条件查询、小表、高重复值字段、LIKE以%开头、联合索引顺序错、范围查询后列等场景无效甚至有害；需结合EXPLAIN、key列、Extra信息综合判断。
索引不是万能的，对某些查询反而拖慢速度
MySQL 索引能加速 WHERE、ORDER BY、GROUP BY 和连接字段的查找，但对全表扫描类查询几乎无益，甚至有害。比如 SELECT * FROM user LIMIT 10 这种无条件查询，加了索引反而让优化器多一次 B+ 树遍历，还占额外磁盘和内存。
- 索引本身需要维护：INSERT/UPDATE/DELETE 时要同步更新索引树，写入变慢
- 小表（如
rows ）加索引收益极低，优化器常直接走全表扫描 - 高重复值字段（如
status TINYINT只有 0/1）建普通索引效果差，SELECT * FROM t WHERE status = 1可能仍触发全表扫描
LIKE 查询以 % 开头时，索引基本失效
LIKE 是否走索引，关键看通配符位置：name LIKE 'abc%' 可用前缀索引，而 name LIKE '%abc' 或 name LIKE '%abc%' 无法利用 B+ 树的有序结构，只能回表或全扫。
- 想支持前后模糊查，可考虑
FULLTEXT索引（仅 MyISAM/InnoDB 的 CHAR/VARCHAR/TEXT 字段） - 或改用倒排索引方案（如 Elasticsearch），MySQL 原生不擅长
- 注意
COLLATION影响：若列是utf8mb4_0900_as_cs，大小写敏感下'ABC%'无法命中'abc'索引
联合索引顺序错，等于白建
联合索引 (a, b, c) 的生效前提是「最左前缀匹配」：能用在 a = ?、a = ? AND b = ?、a = ? AND b = ? AND c = ? 上；但 b = ? 或 b = ? AND c = ? 完全无法使用该索引。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果查询高频是
WHERE b = ? AND c = ?，应建(b, c)或(b, c, a)，而非依赖已有(a, b, c) -
ORDER BY字段也受顺序约束：索引(a, b)可覆盖ORDER BY a, b，但不能覆盖ORDER BY b, a - 区分等值与范围：
WHERE a = 1 AND b > 10 AND c = 5中，c不会走索引（范围查询后列失效）
EXPLAIN 显示 type=ALL 并不总代表没走索引
type=ALL 表示全表扫描，但有时它只是执行计划的“最终阶段”——比如 SELECT COUNT(*) FROM t，即使有主键索引，InnoDB 仍可能选 type=ALL，因为引擎直接遍历聚簇索引叶子节点更高效。
- 真正要看的是
key列：非NULL才说明用了哪个索引 -
rows是预估扫描行数，不是实际返回行数；若远大于结果集，才值得怀疑索引有效性 - 注意
Extra中的Using filesort或Using temporary，比type更反映真实性能瓶颈
索引是否生效，得看具体 SQL 的谓词、排序、连接方式，以及数据分布。别只盯着 CREATE INDEX，先 EXPLAIN，再看 SHOW INDEX，最后验证 Handler<em>read</em>* 状态变量——很多慢查问题，其实出在索引根本没被选中，而不是索引建得不够多。
