MySQL索引失效的典型错误场景
索引不是建了就一定生效，很多查询实际走的是全表扫描。常见触发索引失效的操作包括：
WHERE条件中对索引列使用函数（如
WHERE YEAR(create_time) = 2023）、隐式类型转换（如字符串字段用数字比较：
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))），否则会报错。
