在SQL查询编写过程中，不少开发者为了实现特定的筛选逻辑，会在WHERE子句的条件里对查询列直接进行函数运算，比如用YEAR(create_time) = 2024来筛选某年的数据。这种写法虽然能实现功能，但却存在明显的性能隐患，是数据库优化中需要避免的常见问题。
WHERE中对列做函数运算的核心问题
1. 导致索引失效
数据库索引的存储是基于列的原始值构建的，当对列使用函数运算后，原始值被改变，数据库就无法直接匹配已有的索引结构。比如某张用户表在create_time列上建立了普通索引，执行如下查询时：
-- 对列做函数运算，索引失效 SELECT * FROM user WHERE YEAR(create_time) = 2024;
此时数据库无法使用create_time上的索引快速定位数据，只能进行全表扫描，当表数据量较大时，查询耗时会出现明显增长。
2. 增加查询执行的计算开销
函数运算需要对每一行符合条件的列值进行计算，即使数据库能使用索引过滤部分数据，函数计算本身也会带来额外的CPU开销。如果查询涉及大量数据行，这种额外的计算成本会进一步放大性能问题。
3. 影响查询优化器的判断
SQL查询优化器在生成执行计划时，会基于列的统计信息评估不同执行路径的成本。对列做函数运算后，优化器无法准确获取运算后结果集的预估大小，可能会生成不合理的执行计划，进一步降低查询效率。
正确的优化方案
1. 改写条件避免对列做函数运算
针对时间筛选的场景，可以把函数运算转换为范围查询，比如上面的年份筛选可以改写为：
-- 改写为范围查询，可正常使用索引 SELECT * FROM user WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2025-01-01 00:00:00';
这种写法不需要对create_time列做任何运算，数据库可以直接使用索引进行范围扫描，性能远优于函数运算的写法。
2. 使用生成列并建立索引
如果业务上必须频繁使用某个函数运算的结果做筛选，可以在表中添加生成列，并在生成列上建立索引。比如需要频繁按年份筛选create_time，可以添加如下生成列：
-- 添加生成列 ALTER TABLE user ADD COLUMN create_year INT GENERATED ALWAYS AS (YEAR(create_time)) STORED; -- 在生成列上建立索引 CREATE INDEX idx_user_create_year ON user(create_year);
之后查询时直接使用生成列做条件，就可以正常使用索引：
SELECT * FROM user WHERE create_year = 2024;
3. 函数索引的使用
部分数据库（比如MySQL 8.0+、PostgreSQL）支持函数索引，可以直接对函数运算的结果建立索引，语法如下：
-- 创建函数索引 CREATE INDEX idx_user_create_time_year ON user(YEAR(create_time));
创建函数索引后，原来的函数运算查询也可以使用索引，不过需要注意不同数据库对函数索引的支持范围和限制。
常见误区说明
有些开发者认为只要函数运算在等号右边就不会有问题，比如WHERE id = ABS(10)，这种写法中函数运算的对象是常量，不会影响列的原始值，因此不会触发索引失效的问题，只有对查询列本身做函数运算才会导致上述问题。
另外，并不是所有的函数运算都会导致索引失效，比如某些数据库对UPPER、LOWER等函数有特殊的优化支持，但为了保证SQL的可移植性和性能稳定性，还是建议尽量避免在WHERE条件中对列做函数运算。