SQL索引失效是优化器认为走索引比全表扫描慢或无法利用B+树结构所致；常见原因包括：1.对索引列使用函数/运算；2.隐式类型转换；3.模糊查询左模糊；4.联合索引未按最左前缀匹配。
SQL 索引失效不是数据库“故意不走索引”，而是查询条件或写法让优化器判断：走索引比全表扫描还慢，或者根本无法利用索引结构（B+树）进行快速定位。以下是最常见、最容易踩坑的写法，按实际开发高频场景归类说明。
WHERE 子句中对索引列做函数/运算
索引是基于原始列值构建的有序结构，一旦对列使用函数或计算，数据库就无法直接匹配索引中的存储值。
-
red">❌ 失效写法：
WHERE YEAR(create_time) = 2023、WHERE price * 1.1 > 100、WHERE UPPER(name) = 'ALICE' -
✅ 推荐写法： 改为范围查询或冗余字段。例如：
WHERE create_time >= '2023-01-01' AND create_time ；对 price 做运算的逻辑尽量移到应用层；如需大小写模糊查，可建函数索引（MySQL 8.0+）或添加生成列索引。
隐式类型转换导致索引失效
当 WHERE 条件中索引列与传入值类型不一致时，MySQL 可能自动做类型转换（如字符串转数字），导致无法使用索引。
-
❌ 失效写法： 索引列
user_id是BIGINT，却写成WHERE user_id = '123'（字符串）；或phone是VARCHAR，却用WHERE phone = 13800138000（数字） -
✅ 推荐写法： 保持参数类型与字段定义严格一致；开发中用 PreparedStatement 绑定参数，由驱动自动处理；排查时用
EXPLAIN观察type是否为ALL或key为空。
LIKE 查询以通配符开头
B+树索引按字典序存储，只能高效支持“左前缀匹配”。LIKE '%abc' 无法利用索引快速定位起始位置。
-
❌ 失效写法：
WHERE name LIKE '%admin%'、WHERE title LIKE '%error' -
✅ 推荐写法： 尽量改写为左前缀形式，如
LIKE 'admin%'；若必须模糊全文检索，考虑FULLTEXT索引（MySQL）或独立搜索引擎（Elasticsearch）；短文本可加GENERATED COLUMN + INDEX实现反向索引（如REVERSE(name)）。
OR 条件中部分列无索引
当 WHERE a = 1 OR b = 2，若只有 a 有索引、b 没有，MySQL 往往放弃走索引，退化为全表扫描（尤其在旧版本中）。
-
❌ 失效写法：
WHERE status = 1 OR remark LIKE '%urgent%'（remark 无索引） -
✅ 推荐写法： 拆成
UNION ALL（确保去重逻辑可控）；或为 OR 中所有涉及列都建立合适索引；更优解是重构查询逻辑，避免在关键路径上用高开销的 OR。
联合索引未遵循最左前缀原则
联合索引 (a, b, c) 的有效使用必须从最左列开始连续使用。跳过中间列，后续列索引失效。
-
❌ 失效写法：
WHERE a = 1 AND c = 3（缺少b）、WHERE b = 2 AND c = 3（没用a） -
✅ 推荐写法： 查询条件尽量覆盖最左连续列；必要时为高频组合单独建索引（如
(a, c)）；注意WHERE a = 1 AND b > 10 AND c = 5中，c无法走索引（因b是范围查询，截断了索引下推）。
