为什么在SQL查询中不建议对索引列使用函数
在数据库查询优化中，有一条几乎被奉为金科玉律的原则：尽量避免在WHERE子句中对索引列使用函数。无论是DATE()、SUBSTR()还是YEAR()，这类操作都极有可能让精心设计的索引瞬间“哑火”。这背后的原因，并非数据库优化器不够智能，而是源于B+树索引最底层的存储与匹配逻辑。
函数使索引失效是因为B+树索引存储原始值，而函数运算后无法匹配有序结构；应将函数移至常量侧，如DATE(create_time)='2024-01-01'改为create_time>='2024-01-01' AND create_time<'2024-01-02'。
为什么函数会让索引失效
要理解这一点，得先看看索引是怎么工作的。想象一下，索引就像一本按字母顺序排列的电话簿。如果有一列create_time，其索引存储的就是类似‘2024-01-01 14:23:05’这样的原始时间戳，并且严格按照这个完整的时间顺序排列。
一旦你写下WHERE DATE(create_time) = ‘2024-01-01’这样的查询，情况就变了。数据库优化器会犯难：它无法直接利用这本按“完整时间戳”排序的电话簿，去快速查找所有“日期部分等于某一天”的记录。它被迫退回到最原始的方法——翻开每一页（即每一行数据），先调用DATE()函数取出日期部分，再进行比较。这本质上就是一次全表扫描。
所以说，核心问题在于：优化器将“对索引列施加了不可下推的运算”视为一个信号，它无法将这种计算后的条件，映射回索引原有的有序结构上。索引的快速定位能力，就此被绕过了。
DATE()、YEAR() 等日期函数怎么改写
那么，正确的姿势是什么？核心原则其实很清晰：让索引列以“裸值”的形式出现在比较操作中，而把所有的函数或计算都挪到等式的常量一侧。
- 错误写法：
WHERE DATE(create_time) = ‘2024-01-01’ - 优化写法：
WHERE create_time >= ‘2024-01-01’ AND create_time < ‘2024-01-02’
同理：
WHERE YEAR(create_time) = 2024应改为WHERE create_time >= ‘2024-01-01’ AND create_time < ‘2025-01-01’。- 在PostgreSQL中，类似
WHERE create_time::date = ‘2024-01-01’的类型转换操作也应避免，同样改用范围查询。
这里有个小提示：虽然BETWEEN也能实现范围查询，但它容易在边界精度上出问题（例如BETWEEN ‘2024-01-01’ AND ‘2024-01-01 23:59:59’）。相比之下，使用左闭右开区间（>= 配合 <）不仅更安全，逻辑上也更清晰。
字符串函数如 SUBSTR()、UPPER() 怎么处理
日期函数的问题，在字符串函数上同样存在。像SUBSTR(name, 1, 3) = ‘adm’这样的查询，会破坏索引基于前缀的匹配能力，导致其无法被使用。
面对这类情况，可以按以下思路解决：
- 优先考虑前缀匹配：如果能转化为前缀查询，那是最理想的。例如，将上述查询改为
WHERE name LIKE ‘adm%’，这样就能充分利用name列上的普通B+树索引。 - 从源头设计索引：如果业务上经常需要进行大小写不敏感的匹配，与其在查询时使用
UPPER(name)，不如在创建表或索引时，就为字符列指定不区分大小写的校对规则（例如MySQL的utf8mb4_0900_as_ci）。 - 慎用函数索引：对于某些必须依赖函数结果且查询非常频繁的场景，可以考虑创建函数索引（如PostgreSQL/Oracle支持
CREATE INDEX idx_name ON t(UPPER(name))）。但这是一把双刃剑，它会增加索引维护的开销，影响写入性能，切忌滥用。
容易被忽略的隐含陷阱
除了显而易见的函数调用，还有一些“看起来人畜无害”的写法，其实也暗藏杀机。它们本质上也是对列进行了计算或转换：
- 算术运算：
WHERE id + 0 = 100—— 索引列参与了计算，索引失效。 - 表达式操作：
WHERE username || ‘’ = ‘alice’（PostgreSQL中的字符串拼接）—— 同样是表达式操作，索引无法生效。 - 函数在常量侧：
WHERE create_time = CURDATE()—— 注意，CURDATE()本身就是一个函数（等同于DATE(NOW())）。虽然函数作用在常量侧，但某些情况下优化器可能无法准确估算，稳妥起见应改为WHERE create_time >= CURDATE() AND create_time < CURDATE() + INTERVAL 1 DAY。
最后，给出一个最稳妥的建议：不要凭感觉猜测。任何不确定的查询优化，都应该通过执行EXPLAIN命令来验证。关键要看执行计划中的key字段是否非空（表示使用了索引），以及type字段是否达到了ref或更好的级别（如eq_ref、const）。数据库优化器的实际行为，远比我们“看起来差不多”的直觉要复杂。
