PostgreSQL中可直接为表达式创建函数索引，如CREATE INDEX idx_users_name_upper ON users (UPPER(name))，要求表达式用小括号包裹、无AS别名、所有函数为IMMUTABLE；MySQL 8.0+需通过ADD COLUMN ... STORED生成列再建索引，且查询条件须与索引表达式完全一致才能命中。
PostgreSQL 里怎么给表达式建索引
直接用 CREATE INDEX 加函数调用就行，但必须用小括号包住整个表达式，且不能带别名。比如想加速 UPPER(name) 查询，就得写成：
CREATE INDEX idx_users_name_upper ON users (UPPER(name));不是
CREATE INDEX ... ON users (UPPER(name) AS upper_name) —— 这会报错，AS 在索引定义里不合法。
常见错误是把表达式写成查询里的样子，比如加了 WHERE 或子查询，但索引只接受纯标量表达式。另外注意：表达式里所有函数必须是 IMMUTABLE（例如 UPPER() 是，NOW() 就不是），否则建索引会失败。
-
LOWER()、TRIM()、SUBSTRING()（固定起止位置时）都支持；TO_CHAR(created_at, 'YYYY-MM')也行，但TO_CHAR(created_at, 'YYYY-MM-DD HH24:MI')可能因 locale 不稳定而被拒绝 - 索引字段不能是
NULL安全的自动覆盖 —— 如果表达式结果为NULL，这条记录就不会进索引，查WHERE UPPER(name) IS NULL依然走不了这个索引 - 建完得手动
ANALYZE users，不然优化器可能不知道新索引的存在
MySQL 8.0+ 怎么实现类似功能
MySQL 不叫“函数索引”，叫“生成列 + 普通索引”。必须先加一列，用 STORED 方式持久化表达式结果，再给它建索引。比如加速 JSON_EXTRACT(data, '$.status')：
ALTER TABLE orders ADD status_code VARCHAR(20) AS (JSON_EXTRACT(data, '$.status')) STORED;<br>CREATE INDEX idx_orders_status_code ON orders (status_code);
关键点：必须用 STORED（不是 VIRTUAL），因为只有 STORED 列才能建索引。而且生成列表达式也得是 deterministic 的 —— MySQL 会校验，像 RAND() 或 UUID() 直接被拒。
- 生成列名不能和原列同名，否则语法报错；建议用
_expr后缀，比如name_upper_expr - 如果原表数据量大，
ADD COLUMN ... STORED会锁表并重写全表，生产环境务必在低峰期操作 - WHERE 条件里必须显式写成
WHERE status_code = 'active'，不能写WHERE JSON_EXTRACT(data, '$.status') = 'active'—— 优化器不会自动匹配生成列
为什么 WHERE UPPER(name) = 'JOHN' 有时不走函数索引
最常踩的坑是：查询条件没和索引表达式完全对齐。比如索引建的是 UPPER(name)，但查询写了 WHERE UPPER(TRIM(name)) = 'JOHN' —— 多了个 TRIM()，就对不上了。优化器不会做表达式等价推导。
- 大小写要一致：索引用
UPPER()，查询就不能用LOWER()；反过来也一样 - 字符串处理顺序不能变：索引是
UPPER(REPLACE(name, ' ', ''))，那查询也得照写，不能写成REPLACE(UPPER(name), ' ', '') - PostgreSQL 中，如果表启用了
collation（比如en_US.utf8），而表达式没显式指定，可能触发隐式转换，导致索引失效；稳妥做法是加COLLATE "C"显式声明
函数索引的维护成本和性能边界
这类索引不是“设了就高枕无忧”。每次 INSERT/UPDATE 涉及索引表达式里的字段，数据库都要重新计算函数值并更新索引页 —— 开销比普通索引高。特别是用复杂 JSON 或正则函数时，延迟会明显上升。
- PostgreSQL 中，
pg_stat_all_indexes的idx_scan字段可查索引实际命中次数；长期为 0 的函数索引建议删掉 - MySQL 的生成列会额外占用磁盘空间，
STORED列的数据会双份存在（原 JSON 字段 + 提取后的字符串），大表要注意容量膨胀 - 别为了“看起来整洁”给所有模糊查询都上函数索引 ——
LIKE '%john%'这种没法用任何 B-tree 索引，强行加LOWER()索引也没用
真正有效的函数索引，永远绑定在具体查询模式上：你查什么，就建什么，不多不少。多一层函数、多一个字符处理，就多一分匹配失败的风险。
