一、前言
索引是提升 MySQL 查询速度最直接的手段，但日常开发中很多索引会出现失效问题，即使建立索引，SQL 语句依旧走全表扫描，大表场景下查询耗时成倍增加。
本文整理工作中高频遇到的索引失效场景，附带可复现 SQL 案例与优化写法，规范索引使用习惯，适用于业务表 SQL 优化、慢查询治理场景。

二、索引失效典型场景与优化

1. 查询条件字段参与运算、函数调用
   失效案例：
   sql
   – create_time字段存在索引，使用函数后索引失效
   select * from user_info where DATE(create_time) = ‘2026-07-01’;
   失效原因：数据库无法使用索引检索函数计算后的结果，会全表遍历。
   优化写法：调整条件，让索引字段独立，不参与计算
   sql
   select * from user_info
   where create_time >= ‘2026-07-01 00:00:00’
   and create_time < ‘2026-07-02 00:00:00’;

2. 字符串字段查询不加引号，隐式类型转换
   user_phone 为 varchar 类型且建有索引：
   sql
   – 错误写法，数字匹配字符串触发隐式转换，索引失效
   select * from user_info where user_phone = 13800138000;
   – 正确写法，字符串匹配
   select * from user_info where user_phone = ‘13800138000’;

3. 模糊查询前置百分号 % xx
   sql
   – 前置%无法走索引
   select * from user_info where user_name like ‘%张三’;
   – 后置%可以正常使用索引
   select * from user_info where user_name like ‘张三%’;
   业务需要全模糊匹配时，可考虑全文索引、搜索引擎辅助处理。

4. 联合索引不遵循最左匹配原则
   建立联合索引 idx_name_age (user_name, age)
   sql
   – 缺少最左字段user_name，索引失效
   select * from user_info where age = 20;
   – 遵循最左前缀，正常走索引
   select * from user_info where user_name = ‘小明’ and age = 20;

5. 使用！=、not in、is not null 等否定条件
   这类逻辑会大幅降低索引利用率，数据分布分散时直接放弃索引扫描全表。
   优化思路：拆分查询逻辑，改用 in、等值匹配分页查询。

三、索引设计通用规范
区分度低的字段不建索引（如性别、状态只有 0/1 两种值，索引收益极低）；
单表索引数量控制在 5 个以内，过多索引会降低新增、更新语句执行速度；
联合索引将高频查询、区分度高的字段放在最左侧；
超长字符串不直接建索引，可截取前缀建立前缀索引；
主键默认自带聚簇索引，避免重复创建主键相关索引。

四、验证索引是否生效的方法
使用 explain 关键字解析 SQL 执行计划，重点观察 type 字段：
type 为 all：全表扫描，未使用索引，需要优化；
type 为 ref/range：正常命中索引，查询效率良好；
key 字段显示实际使用的索引名称，无值代表索引失效。
示例：
sql
explain select * from user_info where user_name = ‘小明’;

五、总结
索引优化是数据库性能调优的基础环节，大部分慢查询根源都是索引使用不当。编码阶段规范 SQL 写法、合理设计索引结构，能大幅减少线上慢 SQL 问题，降低数据库服务器压力。
日常迭代上线前，建议对复杂查询 SQL 执行 explain 校验，提前规避索引失效问题。