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 左侧，把计算逻辑移到右侧常量上。
- 用范围替代函数：
create_time >= '2025-12-27 00:00:00' AND create_time - 用前缀匹配替代
LEFT()：phone LIKE '138%'（前提是phone有索引） - 用等值替代算术偏移：
id = 99替代id + 1 = 100 - 若必须模糊开头（如搜索“张三”在任意位置），
MATCH(name) AGAINST('张三' IN NATURAL LANGUAGE MODE)配合FULLTEXT索引，而非普通索引
为什么有些函数看似“能走索引”其实是假象
像 CAST() 或 CONVERT() 在类型一致时可能不触发失效，但这属于优化器特殊处理，不可依赖。更危险的是某些 ORM 自动生成的 SQL，比如把 datetime 字段和字符串拼接成 CONCAT(date_col, ' 00:00:00') 再比较——这本质仍是表达式操作，索引必然失效。
验证是否真走索引，唯一可靠方式是执行 EXPLAIN，看 key 列是否非 NULL、rows 是否显著小于表总行数。别信“看起来快”，生产环境里慢查询往往就藏在这种“看似合理”的函数调用里。
