索引未被使用主因是优化器判定走索引更慢，常见于对索引列用函数、表达式、跳过联合索引左前缀或范围查询后排序失效；冗余、低区分度、高频更新索引会拖慢写入并占空间。
为什么 WHERE 条件里用了索引字段却没走索引
常见现象是执行 EXPLAIN 后发现 type 是 ALL 或 index，哪怕字段上建了索引。根本原因往往不是索引没建，而是 MySQL 优化器判断“走索引反而更慢”。
-
WHERE中对索引列用了函数或表达式，比如WHERE YEAR(create_time) = 2023—— 这会让索引失效，应改写为WHERE create_time >= '2023-01-01' AND create_time - 隐式类型转换 ：比如
user_id是INT类型，但查询写成WHERE user_id = '123'，MySQL 会转成字符串比对，放弃索引 - 使用了不匹配的排序方向：联合索引
(a, b)，ORDER BY a ASC, b DESC可能无法利用索引做排序（5.7+ 支持部分混合方向，但需确认版本） - 数据分布倾斜严重：比如某字段 95% 值为
'active'，即使加了索引，优化器大概率选全表扫描
LIKE 查询什么时候能用上索引
LIKE 是否走索引，只取决于通配符位置，和是否加索引无关。
-
LIKE 'abc%'：可以走索引（最左前缀匹配） -
LIKE '%abc'或LIKE '%abc%'：无法使用 B+ 树索引，除非启用全文索引（FULLTEXT）或改用INFORMATION_SCHEMA等特殊场景 -
LIKE 'ab_c'（下划线单字符匹配）：仍可走索引，因为不破坏有序性 - 注意字符集影响：若字段是
utf8mb4_unicode_ci，某些排序规则可能导致范围估算偏差，间接影响索引选择
联合索引的最左前缀原则到底怎么生效
联合索引 (a, b, c) 不是“只要查了 a 就能用”，而是“从左开始连续匹配”。它的本质是按字典序存储的复合键。
- 能用上索引的查询：
WHERE a = 1、WHERE a = 1 AND b > 10、WHERE a = 1 AND b = 2 AND c IN (3,4) - 不能用上索引的查询：
WHERE b = 2（跳过 a）、WHERE a > 1 AND c = 3（b 没有等值条件，c 断层） - 特别注意：
WHERE a = 1 ORDER BY b DESC, c ASC可以利用索引排序；但WHERE a > 1 ORDER BY b ASC就不行，因为 a 的范围扫描后 b 已无序 - 如果经常查
b和c，不要指望靠调整联合索引顺序“一箭双雕”，该单独建索引就单独建
索引不是越多越好：哪些情况会拖慢写入和占用空间
每多一个索引，INSERT/UPDATE/DELETE 就要多维护一份 B+ 树结构，且所有索引都会占用磁盘和内存。
- 重复索引：比如已有
(a, b)，又建了(a)—— 后者完全冗余，删掉 - 低选择性字段单独建索引意义小：如
gender只有 ‘M’/’F’，除非配合其他条件，否则几乎不被选用 - 大字段前缀索引要谨慎：
VARCHAR(1000)建INDEX(a(10))虽省空间，但可能因前缀重复高导致区分度不足，反而降低查询效率 - 频繁更新的字段不宜建索引：比如
status每秒更新多次，每次都要刷脏页、写 redo log、更新多个索引树
SHOW INDEX FROM users; 用这条命令看实际索引定义，重点关注 Seq_in_index（联合索引中字段顺序）、Cardinality（基数，越接近总行数越好），别只看有没有索引。
真正难的不是建索引，是判断“这个查询在真实负载下，走索引是否真的更快”——它依赖数据量、分布、并发、buffer pool 命中率，而不是语法看起来“应该能走”。
