不用——除非提前建函数索引；数据库不会自动适配普通索引到upper(col)或date(created_at)等函数表达式，需显式创建对应函数索引才能生效。
WHERE 里用 UPPER(col) 或 DATE(created_at) 时，索引到底用不用得上？
不用——除非你提前建了对应的函数索引。数据库不会自动把普通索引“适配”到函数表达式上，哪怕函数只是简单大小写转换。
常见错误现象：EXPLAIN 显示 type: ALL 或 key: NULL，但表明明有 col 上的索引；或者查询慢得离谱，却查不出原因。
- mysql 8.0+、postgresql、oracle 支持函数索引（语法和限制不同）；sqlite 仅支持简单表达式（如
col + 1），不支持函数调用 - 函数必须是「确定性」的：同一输入永远返回同一输出，
NOW()、RAND()这类不能用于函数索引 - 索引列顺序仍重要：如果 WHERE 同时有
UPPER(name) = 'ABC'和status = 'active'，函数索引得建在(UPPER(name), status)上才可能覆盖
PostgreSQL 函数索引怎么写才真正生效？
直接在 CREATE INDEX 里写函数调用，且 WHERE 条件中的表达式必须字面完全一致——包括括号、空格、大小写。
使用场景：模糊搜索前统一转小写、按日期分区字段提取年份、json 字段取值过滤。
示例模板：
CREATE INDEX idx_users_upper_name ON users (UPPER(name));之后这个查询才能走索引：
SELECT * FROM users WHERE UPPER(name) = 'ALICE';- 如果写成
upper(name)（小写函数名），而索引用的是UPPER，PostgreSQL 不会匹配（函数名区分大小写） - 如果 WHERE 是
UPPER(name || '')，哪怕逻辑等价，也不会命中UPPER(name)索引 - 函数索引不继承主键或唯一约束：要唯一性，得显式加
UNIQUE关键字
MySQL 8.0 的函数索引为什么有时像没建一样？
因为 MySQL 要求函数索引列必须「包裹在表达式中」，且表达式不能含用户变量、存储过程变量或子查询——连 CONCAT('a', col) 都不被允许，只接受纯列函数组合。
可安全使用的典型函数：UPPER()、LOWER()、YEAR()、DATE()、JSON_EXTRACT()（带字面路径）。
示例模板：
CREATE INDEX idx_orders_year ON orders (YEAR(order_time));对应查询：
SELECT * FROM orders WHERE YEAR(order_time) = 2024;- 如果写成
WHERE order_time >= '2024-01-01' AND order_time ，普通 B-tree 索引反而更快，函数索引此时无优势 - 函数索引无法用于
ORDER BY UPPER(name)排序优化，除非同时出现在 WHERE 和 ORDER BY 中且表达式一致 - 执行
SHOW CREATE table可确认索引是否创建成功；若报错Error 3751，说明用了不支持的函数或表达式
函数索引的性能代价和隐性兼容问题
函数索引不是免费午餐：它让 INSERT/UPDATE 更慢，因为每次变更都要重新计算函数值并更新索引页；而且它增大了索引体积，尤其对长文本做 UPPER() 时。
更关键的是兼容性陷阱：
- PostgreSQL 的函数索引默认不支持
LIKE前缀匹配（如UPPER(name) LIKE 'A%'），需配合text_pattern_ops操作符类 - MySQL 的函数索引不支持全文检索函数（
MATCH ... AGAINST），也不能用于生成列的虚拟索引回退 - 跨版本迁移时容易遗漏：低版本 MySQL（pg_catalog.pg_is_in_recovery()）不能建索引
最常被忽略的一点：函数索引只加速「精确匹配」或「范围扫描起始点明确」的场景；一旦函数结果不可预测（比如时区转换、NLS 设置影响的大小写），索引就可能失效，且这种失效很难从执行计划里一眼看出。