函数索引是对表达式结果建索引以加速WHERE、ORDER BY或JOIN中函数查询的机制；适用确定性、高频表达式，如LOWER(email)、date(created_at)等；postgresql、mysql 8.0+、oracle原生支持，SQL Server需用计算列模拟；须确保表达式字面一致、处理NULL行为、避免非确定性函数，并通过EXPLAIN验证生效。
函数索引（functional Index）是SQL数据库中提升表达式查询性能的关键手段。它不是对列值建索引，而是对列上计算出的表达式结果建索引。当WHERE、ORDER BY或JOIN条件中频繁使用函数或表达式时，普通索引往往失效，而函数索引能直接加速这类查询。
哪些表达式适合建函数索引
核心原则：表达式必须是确定性（deterministic）、可索引且高频出现在查询条件中。常见适用场景包括：
- 大小写不敏感匹配：如 LOWER(email)，用于
WHERE LOWER(email) = 'A@B.COM' - 日期截断操作：如 DATE(created_at) 或 YEAR(created_at)，支持按天/年筛选
- 字符串前缀提取：如 SUBSTR(phone, 1, 3)，用于区号查询
- jsON字段路径提取：如 json_extract(data, ‘$.status’)（MySQL 8.0+ / PostgreSQL）
- 组合计算字段：如 price * (1 + tax_rate)，用于含税价范围查询
不同数据库的语法与限制
函数索引并非所有数据库都原生支持，实现方式和能力差异较大：
- PostgreSQL：完全支持，语法最灵活：
CREATE INDEX idx_lower_email ON users (LOWER(email));；支持多列函数索引和部分索引 - MySQL 8.0+：通过“函数索引”（实为表达式索引）支持：
CREATE INDEX idx_email_lower ON users ((LOWER(email)));；括号不可省略，仅支持存储引擎InnoDB - Oracle：使用基于函数的索引（Function-Based Index），需确保查询中使用的函数与索引定义完全一致（含空值处理）：
CREATE INDEX idx_name_upper ON employees (UPPER(last_name)); - SQL Server：不支持原生函数索引，但可通过计算列+索引模拟：
ALTER table users ADD email_lower AS LOWER(email); CREATE INDEX IX_users_email_lower ON users(email_lower);
设计时必须避开的坑
函数索引容易因细节疏忽导致“建了却用不上”，关键注意事项：
- 表达式必须字面一致：索引建在 UPPER(name)，查询写成 upper(name)（大小写不同）或 UPPER(TRIM(name))（多嵌套）均无法命中
- NULL值行为要明确：多数数据库中，函数返回NULL的行不会被索引收录；若业务需查
WHERE func(col) IS NULL，需确认该函数是否对NULL输入返回NULL（如 LOWER(NULL) → NULL），否则索引无效 - 避免过度复杂表达式：含子查询、UDF（用户自定义函数）、非确定性函数（如 NOW()、RAND()）的表达式不能建索引
- 注意统计信息更新：某些数据库（如旧版MySQL）不会自动为函数索引收集统计信息，可能影响优化器选择，必要时手动
ANALYZE TABLE
验证是否真正生效
建完索引不能只看“创建成功”，必须验证执行计划：