SQL索引失效源于查询写法、数据类型不匹配、函数使用等隐式操作；如字段套函数、隐式类型转换、LIKE通配符前置、复合索引未遵最左前缀原则等均会导致全表扫描。
SQL索引失效不是“突然发生”的，而是由查询写法、数据类型、函数或转换逻辑悄悄绕过了索引结构。真正影响性能的，往往是那些看似无害的操作——比如在字段上套函数、混用不同字符集、或让数据库自动做隐式类型转换。
字段上使用函数导致索引完全失效
当WHERE条件对索引列直接应用函数（如UPPER()、SUBSTR()、DATE()等），优化器无法利用B+树索引的有序性进行快速定位，只能全表扫描。
- 失效示例：SELECT * FROM users WHERE UPPER(name) = 'ALICE'; —— 即使name有索引，也用不上
- 替代方案：改用范围查询或函数索引（MySQL 8.0+、PostgreSQL支持）；若必须大小写不敏感，可建函数索引：CREATE INDEX idx_name_upper ON users (UPPER(name));
- 注意：MySQL 5.7及以前不支持函数索引，此时需冗余一个全大写字段并建普通索引
隐式类型转换引发索引失效
当WHERE条件中索引列与比较值类型不一致，且数据库执行了隐式转换，就可能放弃索引。常见于字符串与数字、不同字符集字段关联、或带前导空格/零的数值比对。
- 典型场景1（字符串字段 vs 数字值）：SELECT * FROM orders WHERE order_no = 12345; —— 若order_no是VARCHAR类型，MySQL会把所有order_no转成数字比较，索引失效
- 典型场景2（字符集不匹配）：联表时，一表用utf8mb4，另一表用utf8，JOIN字段即使都加了索引，也可能因隐式转换退化为全表扫描
- 自查方法：执行EXPLAIN，看type是否为ALL或index，同时检查Extra列是否出现Using where; Using index以外的提示（如Using temporary或Using filesort常伴随隐式转换）
LIKE模糊查询写法不当
LIKE本身不必然导致索引失效，但通配符位置决定能否走索引。
- 能用索引：WHERE name LIKE 'Jack%' —— 前缀匹配，B+树可定位到'Jack'开头的区间
- 不能用索引：WHERE name LIKE '%ack%' 或 WHERE name LIKE '%ack' —— 无确定起始值，无法利用有序结构
- 小技巧：若业务允许，可用全文索引（MATCH AGAINST）或倒排索引（如Elasticsearch）替代复杂模糊查
其他易忽略的失效点
一些写法表面合理，实则破坏了索引的最左前缀原则或统计信息有效性。
- 复合索引未按顺序使用左侧列：索引为(a, b, c)，但查询只用了WHERE b = ? AND c = ?，跳过a则无法命中
- 对索引列使用NOT、!=、、IS NULL（部分场景）：MySQL通常不走索引（例外：覆盖索引+IS NULL在某些版本下可优化）
- 索引列参与计算：WHERE price * 1.1 > 100 —— 表达式计算后失去原始索引值，等价于函数操作
- 统计信息过期：大量INSERT/UPDATE/DELETE后未ANALYZE TABLE，优化器误判行数，可能主动放弃索引选全表扫描
