MySQL 8.4 函数索引什么时候值得用：表达式匹配、写入成本与执行计划验收

订单列表突然变慢时，最容易想到的是给 created_at 再加一棵普通索引；但如果查询一直写成 DATE(created_at) = '2026-08-25'，普通索引未必能直接帮助它。MySQL 8.4 的函数索引可以把表达式结果纳入索引，不过它有严格的表达式匹配和写入维护成本，不能把“字段被函数包住”简单等同于“加索引就会快”。

先判断：慢点在表达式，还是在数据分布

动手优化之前先把线上正在跑的SQL原样存好，别上来就凭经验改写成你觉得更优雅的版本。假设我们用的订单表结构大概是这样：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  created_at DATETIME NOT NULL,
  status VARCHAR(20) NOT NULL,
  payload JSON NOT NULL,
  KEY idx_orders_created_at (created_at)
);

下面这条语句把列包在 DATE() 里，问题可能来自表达式匹配，也可能来自当天数据本来就占了大多数：

SELECT id, status
FROM orders
WHERE DATE(created_at) = '2026-08-25'
ORDER BY id DESC
LIMIT 50;

先运行 EXPLAIN，记录 key、rows、filtered 和排序方式。若把条件改为 created_at >= '2026-08-25 00:00:00' AND created_at 后计划已经稳定使用普通索引，就没有必要为同一个问题增加一棵表达式索引。

函数索引的关键是表达式匹配

MySQL 8.4 提供的函数索引（functional key parts）支持直接把表达式写进索引定义，注意语法里要求的双括号不能省略。比如你想把订单的datetime类型字段投影成纯日期值做筛选，就可以这么写：

CREATE INDEX idx_orders_created_date
  ON orders ((DATE(created_at)));

EXPLAIN
SELECT id, status
FROM orders
WHERE DATE(created_at) = '2026-08-25'
ORDER BY id DESC
LIMIT 50;

这里要注意三个边界。第一，索引表达式和查询表达式必须保持同一语义，换成 CAST()、不同的数据类型或另一种日期转换方式，都要重新看计划。第二，函数是否允许用于索引表达式要以当前版本文档和实际建表结果为准。第三，排序仍可能需要额外处理：表达式索引解决了过滤，不代表它自动解决 ORDER BY id。

如果你的业务侧能接受用范围条件做筛选，我更建议保留原来的普通索引、调整SQL写法就好；这种方式对表达式变动的兼容性更高，后续往其他数据库迁移的时候成本也低。函数索引更适合查询形态已经跑稳了、调用方多到没法统一全量改写SQL的场景。

第二个场景：JSON 状态筛选不要只看“能建”

另一个大家经常碰到的场景是订单状态字段放在JSON结构里：

SELECT id
FROM orders
WHERE JSON_UNQUOTE(JSON_EXTRACT(payload, '$.state')) = 'paid';

这类查询即使表达式可以建立索引，也要先看数据类型和返回值是否固定。若业务代码有时写入字符串 paid，有时写入数值 1，索引只能让其中一种表达式更快，不能替应用解决脏数据。

更长期的稳妥方案一般是把高频筛选的字段单独提出来做成显式列，或者搭配生成列建普通索引，把字段类型、默认值和数据迁移逻辑都落在表结构定义里。只有当表结构暂时没法改动、表达式逻辑已经跑了很久完全稳定、而且对应查询的访问量高到确实影响体验的时候，才值得把函数索引放到候选优化方案里。

上线前按三组信号验收

先看计划有没有真的选中

在和线上同规模、同数据分布的副本上对比加索引前后 EXPLAIN。不要只看 possible_keys，重点看最终的 key、预估行数、访问类型以及是否还出现大范围回表或额外排序。

再看读写两端的代价

你可以把对应场景的批量查询和真实写入请求放在一起做压测。函数索引存的是表达式计算后的结果，插入或者更新相关字段的时候，数据库要额外做表达式计算、维护对应索引条目，如果最终查询耗时只减少了几毫秒，反而把写入的尾延迟拉高了很多，这个优化就完全不划算。

最后保留回滚动作

DROP INDEX idx_orders_created_date ON orders;

上线的时候要记下索引创建耗时、对应表的空间增量、写入请求的P95/P99延迟、目标SQL实际扫描的行数和报错率。如果上线后发现写入延迟异常上涨，先把调用侧的高优先级查询降级，再按变更窗口删除新索引，绝对不要在业务高峰期随便改索引定义里的表达式凑结果。

常见问题与复盘清单

函数索引是不是能替代所有普通索引？

不是所有场景都适合。原列可以直接写等值、范围、排序条件的时候，用普通索引一般维护成本更低逻辑更简单。函数索引解决的是已经固化的表达式结果的快速访问问题。

为什么建了索引，EXPLAIN 还是不用？

最常见的原因是查询里的表达式写法和索引定义对不上、索引对应结果的区分度太低、统计信息不准，或者排序加回表的额外成本把过滤带来的收益全抵消了。碰到这类情况先逐字比对原SQL和索引里的表达式，再核对对应字段的数据分布就好定位问题。

什么时候应该改成生成列？

如果对应的字段要被多个查询、报表、约束复用，团队希望统一管理字段逻辑和升级路径，带生成列的方案更容易解释和后续运维。函数索引更适合边界明确的局部性能优化场景。

结语：把“能加索引”变成可验证的变更

函数索引不是用来给SQL补漏洞的装饰性方案。先试着用原生范围条件或者普通索引排查问题，确认表达式完全匹配、查询收益高于写入损耗，再把验证过的执行计划、延迟基线和回滚步骤都写进变更记录，才是MySQL 8.4环境下比较稳妥的用法。