MySQL索引失效常见于WHERE中对索引列用函数、隐式类型转换、LIKE左通配、复合索引跳过左列；用EXPLAIN查type（非ALL）、key（非NULL）、rows（不大）确认命中；复合索引需遵守最左前缀匹配原则。

MySQL索引失效的典型错误场景

索引不是建了就一定生效，很多查询实际走的是全表扫描。常见触发索引失效的操作包括：WHERE 条件中对索引列使用函数（如 WHERE YEAR(create_time) = 2025）、隐式类型转换（如字符串字段用数字比较：WHERE mobile = 13800138000）、LIKE 以通配符开头（WHERE name LIKE '%abc'）、或在复合索引中跳过左侧列（如索引是 (a, b, c)，却只查 WHERE b = 1 AND c = 2）。

如何确认某条 SQL 是否命中索引

用 EXPLAIN 查看执行计划是最直接的方式。重点关注 type 字段（const/ref/range 是理想值，ALL 表示全表扫描），以及 key 字段是否显示实际使用的索引名、rows 字段是否明显偏大。

EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'paid';

注意：如果 key 为 NULL，说明该查询完全没用上索引；如果 Extra 出现 Using filesort 或 Using temporary，往往意味着排序或分组无法利用索引完成，需要优化。

复合索引设计的关键原则

复合索引不是字段堆砌，顺序决定可用性。核心规则是“最左前缀匹配”，即查询条件必须从索引最左侧字段开始连续匹配。例如索引 (user_id, status, created_at) 可支持：

• WHERE user_id = ?
• WHERE user_id = ? AND status = ?
• WHERE user_id = ? AND status = ? AND created_at > ?

但不支持：

• WHERE status = ?（跳过 user_id）
• WHERE user_id = ? AND created_at > ?（跳过中间的 status）

另外，等值条件放前，范围条件放后；高区分度字段优先靠左；避免冗余索引（如已有 (a, b)，再建 (a) 就是浪费）。

索引维护与监控建议

索引不是越多越好。每个索引都会增加写操作（INSERT/UPDATE/DELETE）开销，并占用磁盘空间。定期检查低效索引：

• 用 information_schema.statistics 查看索引基数（CARDINALITY）和字段重复率
• 用 sys.schema_unused_indexes（MySQL 5.7+ 启用 sys schema）识别长期未被使用的索引
• 慢查询日志 + pt-query-digest 分析高频低效查询，针对性补索引

特别注意：对频繁更新的字段建索引要谨慎；TEXT/BLOB 类型字段需指定前缀长度（如 INDEX idx_title (title(100))），否则会报错。