索引不是万能的，对某些查询反而拖慢速度
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 = ?完全无法使用该索引。 如果查询高频是
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>*状态变量——很多慢查问题，其实出在索引根本没被选中，而不是索引建得不够多。
