函数使索引失效是因为b+树存储原始值，而where中对索引列用date()等函数需逐行计算，优化器转为全表扫描；应改写为范围查询（如create_time >= '2025-01-01' and create_time
对索引列使用内置函数（如
DATE()、UPPER()、YEAR()、LEFT()）会导致优化器无法利用索引的有序结构，最终选择全表扫描——这不是索引“坏了”，而是优化器主动放弃走 B+ 树搜索路径。为什么函数会让索引失效
MySQL 的 B+ 树索引存储的是字段原始值（比如
'2025-04-18 14:30:00'），不是函数计算后的结果。一旦你在WHERE中写DATE(create_time) = '2025-04-18'，MySQL 就必须对每一行的create_time执行一次DATE()计算，再比对结果。这等价于逐行计算 + 判断，B+ 树的快速定位能力完全用不上。优化器会评估成本：遍历主键（
type: ALL）或遍历二级索引（type: index）可能比走树搜索更便宜，于是直接跳过索引查找逻辑。
EXPLAIN中出现key: NULL且type: ALL是最直接信号- 即使
key非空（比如显示t_modified），但rows接近表总行数、Extra没有Using index condition，也说明只是在全索引扫描，而非高效查找- 函数调用发生在索引列上，是硬性限制；哪怕函数本身很轻量（如
UPPER()），照样失效哪些函数操作会触发这个问题
所有对索引列直接调用的标量函数都会破坏索引匹配能力，常见包括：
- 日期类：
DATE()、YEAR()、MONTH()、DAY()、DATE_FORMAT()- 字符串类：
UPPER()、LOWER()、TRIM()、LEFT()、SUBSTR()、CONCAT()- 数值类：
ABS()、ROUND()、id + 1这类表达式（本质也是函数运算）注意：
LIKE不是函数，但它以%开头（如name LIKE '%明'）同样因无法确定字典序起点而跳过索引，原理不同但结果一致。怎么改写才能重用索引
核心思路是把函数从索引列“移开”，转为对查询值做预处理，或拆成范围条件。
- 日期场景：把
WHERE YEAR(create_time) = 2025改成WHERE create_time >= '2025-01-01' AND create_time- 字符串大小写：如果业务允许，建索引时用
COLLATE utf8mb4_0900_as_cs或确保写入时统一大小写，避免查时用UPPER()- 前缀提取：把
WHERE LEFT(phone, 3) = '138'改成WHERE phone LIKE '138%'（前提是满足最左前缀）- 生成列（MySQL 5.7+）：可添加存储列
ADD COLUMN create_date DATE AS (DATE(create_time)) STORED，再给它建索引，绕过原列函数问题容易被忽略的隐式函数调用
有些“看起来没写函数”的情况，其实 MySQL 在背后悄悄加了转换，一样导致索引失效：
- 字段是
VARCHAR，却传数字：如WHERE phone = 13800138000→ 实际执行CAST(phone AS SIGNED)- 连接字符集与字段字符集不一致：如字段是
utf8mb4，但客户端连接用latin1→ 等价于CONVERT(phone USING latin1)- JOIN 字段字符集不同：两表关联字段字符集不一致，也会触发隐式
CONVERT，不仅影响性能，还可能引发笛卡尔积这类隐式调用不会出现在 SQL 文本里，只能靠
EXPLAIN的Extra字段（如出现Using where; Using index是好的，只有Using where且key为空，就要怀疑类型或字符集是否对齐）和SHOW WARNINGS查看优化器重写后的语句来发现。
为什么在MySQL中对索引列使用内置函数会导致全表扫描？
雨涛同学_8288
2026-07-01
570人浏览
原创
