MySQL在索引字段上做函数计算几乎必然导致索引失效，因B+树只存原始值，优化器无法映射函数结果；显式函数、数学运算、隐式转换、字符串拼接等均触发此问题，应保持WHERE左侧为干净列名或使用MySQL 8.0+函数索引。
MySQL 在索引字段上做函数计算，绝大多数情况下会导致索引失效——不是“可能”，而是“几乎必然”。根本原因在于：B+ 树索引只存原始列值，不存函数结果；优化器无法把 UPPER(name) 或 YEAR(create_time) 映射到已有的索引结构上。
为什么函数会让 B+ 树索引“认不出”数据
索引本质是排序后的原始值 + 行指针。比如 name 列建了索引，B+ 树里存的是 'alice'、'bob'、'Charlie' 这些原样字符串。一旦写成 WHERE UPPER(name) = 'ALICE'，MySQL 就得对每一行的 name 执行 UPPER()，再比对——这等于放弃树形查找，退化为全表扫描。
同理：WHERE DATE(create_time) = '2024-01-01' 会让优化器忽略 create_time 上的索引，因为索引里存的是带时分秒的完整 DATETIME 值，而 DATE() 把它截断了，二者不可对齐。
- 函数调用发生在执行阶段，而索引匹配发生在优化阶段
- 即使你给
UPPER(name)单独建了函数索引（MySQL 8.0+ 支持），那也只是针对这个表达式生效，和原始name索引无关 -
EXPLAIN中key为空、type为ALL、rows接近表总行数，就是典型信号
哪些操作算“函数计算”，容易被忽略
不只是显式函数调用，以下写法同样触发索引失效：
- 数学运算：
WHERE price * 1.1 > 100→ 应改写为WHERE price > 100 / 1.1 - 隐式类型转换：
WHERE mobile = 13812345678（mobile是VARCHAR）→ MySQL 内部转成CAST(mobile AS SIGNED)，索引失效；必须写成WHERE mobile = '13812345678' - 字符串拼接：
WHERE CONCAT(first_name, ' ', last_name) = 'John Doe'→ 即使建了函数索引，也得确保查询写法完全一致 - 日期截断：
WHERE create_time >= DATE_SUB(NOW(), INTERVAL 7 DAY)没问题，但WHERE DATE(create_time) >= '2026-04-14'就不行
预计算方案：什么时候该在应用层算，什么时候该建函数索引
核心原则：让 WHERE 条件左侧保持为“干净的列名”，不做任何变换。
能提前算好，就别让数据库现场算：
- 时间范围查询，把边界值算好传进来：
WHERE create_time BETWEEN '2026-04-14 00:00:00' AND '2026-04-20 23:59:59'，而不是WHERE DATE(create_time) BETWEEN ... - 大小写模糊匹配，应用层统一转大写后查：
WHERE name = 'ALICE'（配合COLLATE utf8mb4_0900_as_cs或建函数索引） - 前缀匹配优先用
LIKE 'abc%'，不用SUBSTRING(name, 1, 3) = 'abc'
只有当业务逻辑强依赖某表达式、且查询高频时，才考虑 MySQL 8.0+ 的函数索引：CREATE INDEX idx_upper_name ON users ((UPPER(name)));。注意括号语法、表达式必须完全一致，且该索引仅对该表达式生效。
FORCE INDEX 不是救命稻草
FORCE INDEX 只能强制走某个物理索引，但无法绕过“函数导致无法使用索引”的底层限制。比如 WHERE UPPER(name) = 'ABC' FORCE INDEX(idx_name)，依然会全表扫描——因为 idx_name 里根本没有 UPPER(name) 的有序结构。
真正要检查的，是 EXPLAIN 输出里的 key_len 和 Extra 字段：Using where; Using index 是理想状态；Using where; Using filesort 或空 Extra 往往意味着索引没被有效利用。最易被忽略的是联合索引中范围查询后的字段失效——哪怕写了 AND age = 25，只要前面有 city > 'A'，age 就不走索引。
