函数下推不保证索引可用，索引生效前提是 WHERE 中索引列以原始形式参与比较；如 UPPER(name)=’ALICE’ 无法走 name 索引，而 name=’alice’ 可以。
SQL 数据库中函数下推（Function Pushdown）和索引利用是性能优化的关键环节，但二者存在天然张力：对字段施加函数操作常导致索引失效，即使该字段本身已建索引。理解其限制条件与触发索引的边界，才能写出真正高效的查询。
函数下推不等于索引可用
所谓“函数下推”，是指数据库将计算逻辑（如 red”>UPPER()、DATE()、SUBSTR() 等）从应用层或执行器下推至存储层处理，以减少数据传输或利用底层加速能力。但这不意味着索引能被使用——索引是否生效，取决于WHERE 子句中过滤列是否以“索引列本身”形式参与比较，而非其函数变换结果。
例如：
- WHERE name = ‘alice’ → 若 name 有 B -Tree 索引，可走索引查找
- WHERE UPPER(name) = ‘ALICE’ → 即使 name 有索引，也通常无法直接利用，因索引中存的是原始值，不是大写后值
- WHERE created_at > DATE(‘2024-01-01’) → 若 created_at 是 DATETIME 类型且有索引，DATE()会截断时间部分，导致范围扫描失效或退化为全表扫描
哪些函数可能保留索引能力？
部分数据库（如 MySQL 8.0+、PostgreSQL、TiDB）支持函数索引（Functional Index）或隐式可下推的确定性表达式，但需满足严格条件：
- 确定性（Deterministic）：相同输入永远返回相同输出，无随机、会话变量、当前时间等依赖
- 单调性（Monotonic）或可转换性 ：如WHERE YEAR(create_time) = 2024 在 MySQL 中仍可能用上 create_time 索引（因优化器可重写为 create_time BETWEEN ‘2024-01-01’ AND ‘2024-12-31 23:59:59’），但MONTH(create_time) = 6 一般不行
- 前缀函数 + 前缀索引匹配 ：如 MySQL 中对email 建前缀索引 INDEX idx_email (email(10))，则WHERE email LIKE ‘abc%’ 可命中；但 WHERE SUBSTR(email, 1, 3) = ‘abc’ 通常不可
索引能用的典型安全写法
绕过函数导致的索引失效，核心思路是 把函数从索引列移到参数侧，让索引列保持裸露参与比较：
- 大小写匹配 → 建立大小写不敏感的排序规则（如 MySQL 的utf8mb4_0900_as_cs）或函数索引：CREATE INDEX idx_name_upper ON t1 (UPPER(name))
- 日期范围 → 避免WHERE DATE(create_time) = ‘2024-01-01’，改用：WHERE create_time >= ‘2024-01-01’ AND create_time
- 字符串前缀 → 用 LIKE ‘prefix%’ 而非LEFT(col, N) = ‘prefix’；后者几乎总无法走索引
- 数值范围转换 → WHERE FLOOR(price) = 99应改为：WHERE price >= 99 AND price
验证是否真走了索引
不能只看执行计划里有没有“index”字样，要关注实际访问方式：
- MySQL 中用 EXPLAIN FORMAT=JSON 查key、rows、filtered及 using_index 是否为 true
- PostgreSQL 中用 EXPLAIN (ANALYZE, BUFFERS)，重点看Index Scan 还是 Seq Scan，以及Rows Removed by Filter 比例
- 注意“索引覆盖扫描（Index Only Scan）”和“回表（Using index condition）”的 区别：前者仅读索引页，后者还需回主键查数据页
