在mysql的查询优化场景中，索引是提升查询效率的核心手段，但很多不当的sql写法会导致索引无法被正常使用，其中索引列参与函数计算就是典型的情况。这种写法往往会让原本可以快速定位数据的索引失去作用，导致查询走全表扫描，性能大幅下降。
索引列参与函数计算为什么会失效
mysql的B+树索引是按照索引列的原始值有序存储的，当对索引列使用函数计算时，数据库无法直接利用原有有序的索引结构匹配数据，只能对每一行数据先计算函数结果再判断条件，自然就无法使用索引。
比如我们有一个用户表user，其中create_time字段建立了普通索引，现在要查询2024年创建的用户，错误的写法如下：
-- 错误写法：索引列参与函数计算，索引失效 SELECT * FROM user WHERE YEAR(create_time) = 2024;
这里对create_time使用了YEAR()函数，mysql无法直接通过create_time的索引定位2024年的数据，会遍历全表计算每一行的年份再筛选。
常见的索引列函数计算失效场景
1. 日期时间类函数
除了上面的YEAR()，常见的DATE()、MONTH()、DAY()、NOW()等函数作用于索引列时，都会导致索引失效。
2. 字符串类函数
比如对varchar类型的索引列使用UPPER()、LOWER()、SUBSTRING()等函数，同样会让索引无法使用。
-- 错误写法：字符串索引列参与函数计算 SELECT * FROM user WHERE UPPER(username) = 'ZHANGSAN';
3. 数值计算类函数
对数值类型的索引列做加减乘除、ABS()、ROUND()等计算，也会触发索引失效。
-- 错误写法：数值索引列参与计算 SELECT * FROM order WHERE amount + 10 > 100;
如何优化这类问题
核心思路是避免对索引列直接做函数计算，把计算逻辑转移到条件值的另一侧，或者调整查询条件的形式。
优化日期时间查询
上面的年份查询可以改成范围查询，直接利用create_time的索引：
-- 优化后写法：条件值做范围匹配，索引生效 SELECT * FROM user WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2025-01-01 00:00:00';
优化字符串查询
如果是大小写不敏感的查询，可以调整字段的排序规则为不区分大小写，或者在插入数据时统一格式，避免查询时使用UPPER()：
-- 优化后写法：直接匹配，索引生效 SELECT * FROM user WHERE username = 'zhangsan';
优化数值计算查询
把计算转移到条件值上：
-- 优化后写法：计算放在值侧，索引生效 SELECT * FROM order WHERE amount > 90;
特殊情况说明
并不是所有函数计算都会导致索引失效，mysql8.0及以上版本支持的函数索引可以解决这个问题。如果经常需要对某个索引列做固定的函数计算查询，可以创建对应的函数索引：
-- 创建函数索引 CREATE INDEX idx_create_time_year ON user (YEAR(create_time)); -- 此时查询可以使用该函数索引 SELECT * FROM user WHERE YEAR(create_time) = 2024;
不过函数索引会占用额外的存储空间，并且只适用于固定的函数计算场景，实际使用中需要根据业务需求权衡是否创建。
总结
在mysql5.7及以下的版本中，普通索引列参与函数计算基本都会导致索引失效，需要尽量避免这类写法。如果使用的是mysql8.0及以上版本，可以通过创建函数索引来兼容这类查询场景。日常写sql时，建议先通过EXPLAIN命令分析查询计划，确认索引是否被正常使用，再针对性做优化。