SQL索引失效原因有哪些_常见错误场景全面总结【教程】

SQL索引并非建了就生效，失效主因是破坏有序性、确定性或原始值匹配；函数操作、类型不匹配、OR含非索引字段及联合索引顺序不当均会导致全表扫描。

SQL索引不是“建了就一定生效”，很多看似合理的查询，实际执行时却绕过索引走全表扫描。根本原因在于：索引（尤其是B+树）依赖有序性、确定性、原始值匹配——一旦破坏这三点，优化器就无法安全、高效地使用它。

函数或表达式操作索引列

对索引字段使用函数（如 YEAR()、SUBSTR()、UPPER()）、运算（如 age + 1 = 25）或类型转换（如 CAST()），会导致索引失效。

• ❌ 错误写法：WHERE YEAR(create_time) = 2023 或 WHERE name LIKE CONCAT('%', ?)
• ✅ 正确写法：WHERE create_time >= '2023-01-01' AND create_time
• ? 提示：若必须用函数查询，可考虑函数索引（MySQL 8.0+ 支持）或冗余生成列+索引

模糊查询位置不当

LIKE 匹配是否走索引，取决于通配符位置。B+树按字符串前缀排序，只能高效支持“左对齐”查找。

• ❌ 不走索引：LIKE '%张'、LIKE '%三%'（首部含 %）
• ✅ 可走索引：LIKE '张%'（前缀匹配）、LIKE '张_明'（固定长度通配）
• ⚠️ 注意：LIKE '张%' ESCAPE '\' 中转义符不影响索引使用，但需确保语义清晰

联合索引未遵守最左前缀原则

复合索引 (a, b, c) 的 B+ 树叶子节点按 a → b → c 排序。跳过左侧列，后续列无法定位。

标签： mysql ai 隐式转换