索引失效会引发全表扫描，增加查询响应时间。通过EXPLAIN分析执行计划，观察type为ALL、key为NULL时表明未使用索引。常见原因包括：对索引列使用函数（如YEAR）、隐式类型转换、OR连接非索引字段、违反复合索引最左前缀原则、LIKE以%开头、数据量小或选择性差、使用NOT/!=等否定操作。优化方式为避免函数操作、确保类型一致、合理设计复合索引、改写SQL或使用覆盖索引，并结合慢查询日志持续监控与调整。
MySQL索引失效会影响查询性能，导致全表扫描，增加响应时间。要分析索引是否失效，可以从执行计划入手，结合常见场景判断原因。
查看执行计划（EXPLAIN）
使用 EXPLAIN 命令是分析索引是否生效的第一步。重点关注以下字段：
- type：访问类型，ALL 表示全表扫描，通常意味着索引未被使用；ref、range、const 表示索引有效。
- key：实际使用的索引名称，为 NULL 则表示未使用索引。
- possible_keys：可能用到的索引，如果这里为空，说明没有相关索引可用。
- rows：扫描行数，数值越大，效率越低。
例如：
EXPLAIN SELECT * FROM users WHERE name = 'John';
如果 key 为 NULL，且 type 为 ALL，说明该查询未走索引。
常见索引失效原因
以下是导致 MySQL 索引失效的典型情况：
1. 查询条件中对字段使用函数或表达式
在索引列上使用函数会导致索引无法命中。
SELECT * FROM users WHERE YEAR(create_time) = 2023;
即使 create_time 有索引，YEAR() 函数会使索引失效。应改为：
SELECT * FROM users WHERE create_time >= '2023-01-01' AND create_time < '2024-01-01';
2. 隐式类型转换
当查询字段与条件值类型不匹配时，MySQL 会自动转换，导致索引失效。
SELECT * FROM users WHERE user_id = '123';
如果 user_id 是整型，而传入的是字符串 '123'，可能会触发类型转换，使索引失效。应确保类型一致：
SELECT * FROM users WHERE user_id = 123;
3. 使用 OR 连接非索引字段
如果 OR 条件中有一侧字段无索引，可能导致整个 WHERE 条件无法使用索引。
SELECT * FROM users WHERE indexed_column = 'a' OR non_indexed_column = 'b';
建议拆分查询或为 non_indexed_column 添加索引。
4. 最左前缀原则未遵守（复合索引）
复合索引 (A, B, C) 要求查询从最左列开始。以下情况无法使用索引：
- 只查 B 或 C 字段
- 跳过 A 只查 B 和 C
正确使用方式是包含 A，如 A=1、A=1 AND B=2。
5. 模糊查询以 % 开头
LIKE 查询以通配符开头会破坏索引结构。
SELECT * FROM users WHERE name LIKE '%john';
这种写法无法使用索引。若必须模糊匹配，可考虑全文索引或使用覆盖索引优化。
6. 数据分布倾斜或数据量小
当 MySQL 优化器认为全表扫描比走索引更快时（如数据量少、选择性差），会主动放弃索引。
例如，某个字段只有两个值（如性别），即使加了索引，查询时也可能不使用。
7. 使用 NOT、!=、NOT IN 等否定操作
这些操作通常无法有效利用索引，容易导致全表扫描。
SELECT * FROM users WHERE status != 1;
可尝试改写为明确的范围或使用其他逻辑规避。
如何避免和修复
- 定期使用 EXPLAIN 分析慢查询语句
- 遵循最左前缀原则设计复合索引
- 避免在索引列上做运算或隐式转换
- 合理使用覆盖索引减少回表
- 监控慢查询日志，及时优化 SQL
- 必要时使用 FORCE INDEX 强制走索引（慎用）
基本上就这些。索引失效多数源于 SQL 写法不当或设计不合理，通过执行计划分析和规范编码习惯可以有效规避。
