MySQL在索引列上使用函数后通常无法命中索引，核心原因在于优化器难以进行索引范围推导。由于函数运算破坏了 B+ 树依赖的原始值有序性，数据库无法基于索引快速定位数据；正确做法是把计算放到条件右侧，使用范围查询替代函数判断，例如create_time >= '2025-12-27 00:00:00' AND create_time < '2025-12-28 00:00:00'。
MySQL 对索引字段使用函数后之所以不能走索引，并不是因为“语法不允许”，而是因为查询优化器无法继续做索引范围分析。索引本质上是按照字段原始值有序存储的，一旦给列套上函数，就相当于对整列数据重新计算，原有的顺序性和可定位能力都会被打破。
函数操作让索引“不可见”
索引（B+树）之所以查询效率高，关键就在于字段原始值天然有序，可以据此进行快速查找。举个典型例子，假设 create_time 字段上建立了索引，那么 B+ 树节点中存放的是类似 '2025-12-27 14:30:00' 这样的完整时间值。如果查询条件写成 DATE(create_time) = '2025-12-27'，情况就完全不同了：MySQL 需要先对每一行的 create_time 执行一次 DATE() 计算，再将结果进行比较。这样一来，B+ 树基于原始值排序的优势就无法利用，数据库也不能通过索引有序性直接过滤无关数据，最终往往只能退化为全表扫描。
常见导致索引失效的写法包括：
YEAR(create_time) = 2025LOWER(name) = 'tom'LEFT(phone, 3) = '138'id + 1 = 100
怎么改才真正生效
核心优化原则是：让索引列以“裸列”形式出现在 WHERE 条件左侧，把函数计算或表达式处理移动到右侧常量中，这样 MySQL 才更容易使用索引。
- 用范围查询替代函数：
create_time >= '2025-12-27 00:00:00' AND create_time < '2025-12-28 00:00:00' - 用前缀匹配替代
LEFT()：phone LIKE '138%'（前提是phone字段已建立索引） - 用等值条件替代算术运算：
id = 99替代id + 1 = 100 - 如果必须做任意位置的模糊搜索（例如查找“张三”出现在任意位置），应使用
MATCH(name) AGAINST('张三' IN NATURAL LANGUAGE MODE)配合FULLTEXT全文索引，而不是依赖普通索引
为什么有些函数看似“能走索引”其实是假象
像 CAST()、CONVERT() 这类函数，在字段类型本来一致的情况下，有时看起来似乎不会导致 MySQL 索引失效，但这通常只是优化器做了特定兼容处理，并不能当作稳定、通用的 SQL 优化规则。真正需要注意的，往往是某些 ORM 框架自动生成的 SQL，比如把 datetime 字段和字符串拼接成 CONCAT(date_col, ' 00:00:00') 再参与比较。本质上，这仍然是在索引列上做表达式运算，因此索引失效几乎是大概率事件。
要判断查询是否真正使用了索引，最可靠的方法仍然是执行 EXPLAIN，重点查看 key 列是否不是 NULL，以及 rows 的扫描行数是否明显小于整表数据量。不要只凭“执行起来好像不慢”来判断，很多 MySQL 慢查询问题，恰恰就隐藏在这种表面合理、实际上破坏索引的函数调用中。
