在报表类系统的SQL查询里，开发人员经常为了展示方便，在SELECT或WHERE子句中对字段直接套用函数。比如按月份统计订单，会写成WHERE MONTH(create_time) = 6。这种做法在语法上没问题，但会让原本建立在create_time上的索引无法被使用，数据库只能全表扫描，数据量大时报表接口非常慢。
一、为什么函数会让索引失效
数据库索引存储的是列的原始值，并通过有序结构快速定位。如果在列上包裹函数，优化器面对的是函数计算后的结果，它无法知道MONTH(create_time)与原索引值的对应关系，于是放弃索引路径。
以下写法会导致索引失效：
-- 在列上使用函数，索引失效 SELECT id, order_no FROM t_order WHERE MONTH(create_time) = 6;
二、函数改写优化方案
1. 把函数移到常量侧
保持索引列干净，将条件改写为范围查询，让列直接比较：
-- 改写为范围，索引可用 SELECT id, order_no FROM t_order WHERE create_time >= '2023-06-01' AND create_time < '2023-07-01';
2. 建立函数索引
若业务必须按函数结果过滤，可建函数索引，相当于为计算结果单独建索引：
-- 创建函数索引 CREATE INDEX idx_month_create ON t_order (MONTH(create_time)); -- 查询仍可使用该函数索引 SELECT id, order_no FROM t_order WHERE MONTH(create_time) = 6;
3. 派生列加普通索引
在表上增加一个month字段，写入时维护，对其建普通索引，报表查询直接用它过滤。
| 方案 | 适用场景 | 维护成本 |
|---|---|---|
| 范围改写 | 时间类函数 | 低 |
| 函数索引 | 固定函数逻辑 | 中 |
| 派生列 | 高频报表维度 | 高 |
三、改写时的注意点
- 避免在WHERE中对索引列做隐式转换，如字符串列用数字比较。
- 使用
EXPLAIN查看执行计划，确认type列不再是ALL。 - 报表统计优先汇总到中间表，减少在线函数计算。
核心原则：索引列保持原样参与比较，把计算推给常量或预计算层。
通过上述函数改写，报表SQL可以从全表扫描回到索引范围扫描，响应时间通常能下降一个数量级，保障后台分析流畅。