mysql对索引列使用函数后无法走索引，根本原因是优化器无法做索引范围推导，因函数破坏了b+树依赖的原始值有序性；应将计算移至右侧，用范围条件替代函数，如create_time >= '2025-12-27 00:00:00' and create_time

MySQL 对索引列使用函数后无法走索引，根本原因不是“语法禁止”，而是优化器无法做索引范围推导——索引是按原始值有序存储的，一旦对字段套函数，就等于把整列数据重新计算一遍，失去了有序性和可定位性。

函数操作让索引“不可见”

索引（B+树）依赖字段原始值的排序结构快速定位。比如 create_time 有索引，其 B+ 树节点存的是 '2025-12-27 14:30:00' 这样的完整时间戳。但当你写 DATE(create_time) = '2025-12-27'，MySQL 必须对每一行的 create_time 执行 DATE() 函数，再比对结果。这时它无法利用 B+ 树的有序性跳过无关分支，只能全表扫描。

常见失效写法包括：

OGT Docs Create

在文档优先系统中创建新的文档实体。路由至专门的任务、定义、规则、功能及社交内容创建子技能。用于添加任何新文档。

下载

• YEAR(create_time) = 2025
• LOWER(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 是否显著小于表总行数。别信“看起来快”，生产环境里慢查询往往就藏在这种“看似合理”的函数调用里。