SQL索引失效原因_常见索引失效场景总结

5次阅读

SQL索引失效原因_常见索引失效场景总结

索引不是加了就一定生效,很多看似合理的写法,实际执行时根本没走索引。核心问题在于:数据库优化器无法将查询条件与索引结构对齐。下面整理出最常见、最容易踩坑的几类场景,每类都说明原因和可落地的改法。

对索引列用函数或表达式

索引里存的是原始值,一旦在 WHERE 中对列做计算(比如 YEAR(create_time)username + ‘abc’SUBSTR(name, 1, 5)),优化器就无法直接比对索引项,只能全表扫描。

  • ❌ 失效写法:WHERE date(create_time) = '2024-01-01'WHERE id * 2 = 100
  • ✅ 改法:把计算移到右边,或改用范围匹配
    WHERE create_time >= '2024-01-01' AND create_time <br>→ <code>WHERE id = 100 / 2
  • ? 补充:postgresqloracle 支持函数索引(如 CREATE INDEX idx ON log(DATE(create_time))),但会增加写入负担,不建议滥用。

隐式类型转换

当查询值类型和索引列类型不一致时,数据库会自动做类型转换——本质是对索引列加了 CAST 或 TO_CHAR 等函数,导致索引失效。

  • ❌ 常见例子:WHERE user_id = 123(user_id 是 VARCHAR)
    WHERE age = '25'(age 是 int
  • ✅ 原则:让两边类型严格一致
    字符串字段就用引号:WHERE user_id = '123'
    → 数值字段就别加引号:WHERE age = 25
  • ⚠️ 注意:mysql 对数字字段传字符串有时仍能走索引(如 id = '2'),但这属于兼容行为,不可依赖;其他数据库更严格,务必统一类型。

LIKE 左模糊或全模糊

B+ 树索引按字符顺序存储,只支持“从左到右”匹配前缀。一旦通配符 % 出现在开头,就失去了定位起点的能力。

  • ❌ 失效写法:WHERE name LIKE '%ton'WHERE name LIKE '%john%'
  • ✅ 可选方案:
    → 改成右模糊:WHERE name LIKE 'john%'(可走索引)
    → 需要全文检索场景,改用 FULLTEXT 索引或 elasticsearch
    → MySQL 8.0+ 支持倒序索引(CREATE INDEX idx_name_rev ON t((REVERSE(name)))),可支持后缀查询,但使用较少。

联合索引未满足最左前缀

联合索引 (a, b, c) 的 B+ 树是先按 a 排序,a 相同时再按 b,b 相同再按 c。跳过左侧列,就等于找不到入口。

  • ❌ 失效写法:WHERE b = 2 AND c = 3(没出现 a)
    WHERE a = 1 AND c = 3(跳过了 b)
  • ✅ 正确用法:
    → 必须包含最左列:WHERE a = 1WHERE a = 1 AND b = 2WHERE a = 1 AND b = 2 AND c = 3
    → 范围查询注意顺序:WHERE a = 1 AND b > 10 AND c = 'x' 中,c 很可能失效(因 b 是范围,c 在其右侧);如需 c 生效,应把 c 放 b 前面建索引((a, c, b)

OR 条件中存在非索引列

优化器面对 OR 时,如果任一条件无法走索引,往往放弃索引合并策略,直接全表扫描——因为代价模型认为不如扫一遍来得快。

  • ❌ 失效写法:WHERE name = 'Tom' OR age = 25(name 有索引,age 没有)
    WHERE id > 100 OR status != 'done'(后者通常不走索引)
  • ✅ 替代方案:
    → 给 OR 所有字段都加索引(如 INDEX(age)
    → 拆成 unionselect ... WHERE name = 'Tom' UNION SELECT ... WHERE age = 25(各子句可独立走索引)
    → 改用 IN(当右侧为确定值列表):WHERE name IN ('Tom', 'Jerry')

不等于、NOT、IS NULL 等否定操作

这类条件通常返回大量数据,优化器评估后认为回表成本高,不如全表扫描一次更省事——尤其当没有覆盖索引时。

  • ❌ 常见失效:WHERE status != 'paid'WHERE name NOT LIKE 'A%'WHERE score IS NULL
  • ✅ 应对思路:
    → 尽量用肯定逻辑重写:WHERE status IN ('pending', 'failed')
    → 若必须否定,确保查询能走覆盖索引(SELECT 只查索引列),避免回表
    → 对 NULL 查询,可单独为该列建索引并配合 WHERE col IS NULL,部分版本支持
text=ZqhQzanResources