MySQL 生成列为什么不能引用不确定函数

我第一次给业务表加生成列时，想做一件看起来很合理的事：把用户年龄算出来存进表里。生日已经有了，CURDATE() 也能拿到今天，按理说写成一列就完事。结果 DDL 直接被 MySQL 拒绝了。

后来我才意识到，生成列不是“把一段查询语句藏进表结构”，它更像一个必须稳定兑现的约定：只要基础列没变，生成结果就应该能被重复计算出来。函数如果会随着时间、连接或环境变化，生成列和索引就没有可靠的依据。

我踩到的第一个坑：今天的年龄不是列值

下面这段写法很符合人的直觉，但它把“当前时间”混进了列定义：

CREATE TABLE user_profile (
    id BIGINT PRIMARY KEY,
    birthday DATE NOT NULL,
    age INT AS (TIMESTAMPDIFF(YEAR, birthday, CURDATE())) STORED
); -- 中文说明：年龄随今天变化，不适合固化成生成列

MySQL 8.4 的生成列规则要求表达式使用字面量、运算符和确定性内置函数。确定性可以简单理解为：给定相同的表中数据，多次计算应得到同一个结果，并且不能依赖当前连接用户。NOW()、CONNECTION_ID()、CURRENT_USER() 都属于官方文档列出的不确定函数，CURDATE() 也有同样的问题。

这不是 MySQL 故意为难人。假如今天算出 28 岁，明天同一行基础列没变却应该变成 29 岁，那么 STORED 值、虚拟列读取结果和基于它建立的索引就不再是同一件事。对我来说，遇到这类需求时最先要问的不是“怎么绕过 DDL”，而是“这个值到底是不是数据本身”。

能放进去的，通常是同一行数据的稳定变换

我把生成列表达式分成两类看，判断会快很多。第一类是“同一行换一种表示”：把邮箱转小写、从 JSON 中取出固定字段、把两个姓名列拼成展示名。第二类是“结果会随外部状态变”：当前时间、随机数、连接身份、查询其他表。

CREATE TABLE customer_profile (
    id BIGINT PRIMARY KEY,
    email VARCHAR(200) NOT NULL,
    profile JSON NOT NULL,
    email_key VARCHAR(200) AS (LOWER(email)) STORED,
    level_key VARCHAR(32) AS (
        JSON_UNQUOTE(JSON_EXTRACT(profile, '$.level'))
    ) VIRTUAL,
    KEY idx_email_key (email_key)
); -- 中文说明：这些结果只依赖当前行，可作为检索或统一读取入口

这里的重点不是把所有清洗逻辑都塞进表里，而是让重复出现、规则稳定的表达式有一个明确名字。MySQL 文档还特别提醒，生成列表达式不能使用子查询、变量、存储函数和可加载函数；引用其他生成列时，只能引用定义在前面的列。

还有一个容易混淆的地方：函数名字听起来“纯”，不等于它在当前场景下一定满足生成列规则。遇到不熟悉的函数，我会先查对应版本的官方手册，再用一张临时表验证，而不是凭经验把 DETERMINISTIC 写进某个存储函数定义里就认为安全。

年龄、JSON 和索引，我现在会这样分开处理

年龄是动态值，查询时计算更诚实：

SELECT
    id,
    TIMESTAMPDIFF(YEAR, birthday, CURDATE()) AS age
FROM user_profile
WHERE id = 1001; -- 中文说明：每次读取都按当天计算，不把年龄伪装成稳定列值

JSON 中的会员等级就不一样了。只要 profile 这一行没变，提取路径的结果就稳定，可以用虚拟生成列统一查询；如果这个字段经常作为筛选条件，再考虑存储或建立索引。这样既没有把“今天”写进表结构，也避免每个查询都重复写一长段 JSON 表达式。

我会把选择简单化：

为什么能建表还不够：索引表达式也要对得上

生成列建成功之后，我还会专门检查查询写法。MySQL 8.4 支持利用生成列索引优化查询，但表达式要匹配，结果类型也要一致。比如生成列定义是 f1 + 1，查询里写成 1 + f1，优化器不一定把它当成同一个表达式。

CREATE TABLE event_log (
    id BIGINT PRIMARY KEY,
    payload JSON NOT NULL,
    event_name VARCHAR(100) AS (
        JSON_UNQUOTE(JSON_EXTRACT(payload, '$.name'))
    ) STORED,
    KEY idx_event_name (event_name)
); -- 中文说明：JSON_UNQUOTE 让索引列与字符串比较保持一致

EXPLAIN SELECT id
FROM event_log
WHERE event_name = 'signup'; -- 中文说明：验收时确认查询表达式和生成列语义一致

我的验收清单通常只有三步：先确认 DDL 能创建，再插入一行看生成值，最后用 EXPLAIN 看真实查询是否有机会使用索引。只看到“表创建成功”还不算完成，因为表达式可用和查询路径有效是两件事。

最后的取舍：别为了少写一段 SQL 牺牲语义

现在再遇到生成列报错，我会先按“是否只依赖本行稳定数据”筛一遍。是，就继续看函数、类型和索引；不是，就把计算放回查询层、应用层或定时汇总。尤其是年龄、距离今天多久、当前用户身份这类词，天然带着时间或上下文，强行生成列往往只是把问题藏起来。

生成列真正舒服的地方，是把稳定且重复的表达式变成表结构的一部分；它不适合替代所有业务计算。对我来说，这个边界一旦想清楚，MySQL 拒绝某个函数就不再像语法报错，而是在提醒：这列其实没有你想象得那么稳定。

相关问题

生成列一定要用 STORED 才能建索引吗？

不一定。MySQL 8.4 的 InnoDB 支持虚拟生成列上的二级索引，STORED 生成列也可以建立索引；具体选择要结合存储成本、计算成本和查询频率。

把当前时间先存进普通列，再用生成列可以吗？

可以，但那已经改变了语义：你保存的是写入时刻或业务确认时刻，而不是每次读取时的“现在”。列名和注释最好把这个时间点说清楚，避免后续把它误当成实时年龄或实时状态。

参考：MySQL 8.4 官方文档：CREATE TABLE and Generated Columns；MySQL 8.4 官方文档：Optimizer Use of Generated Column Indexes。