前言

最近在做订单系统重构时，遇到了一个有趣的问题。

系统里有很多地方都要计算订单的总价（数量×单价），这个计算逻辑分散在各个服务中，产生了不少相似甚至重复的代码。

代码评审时，同事提出了一个建议 —— 使用MySQL的虚拟列来统一处理这类计算，在调研后我们一致决定采纳。

经过一段时间的生产实践，也逐渐摸清了虚拟列的套路，这里就和大家分享一下这个特性的使用心得。

耐心看完，你一定有所收获。

MySQL 5.7版本引入的虚拟列（Generated Columns）允许我们定义一个基于其他列计算得出的列。

它有点像Excel中的计算列，但更加强大和灵活。

虚拟列分为两种类型：

1. VIRTUAL（虚拟列）：在读取时实时计算，不占用存储空间
2. STORED（存储列）：在数据写入时计算并存储，会占用实际存储空间

基本语法

创建虚拟列的语法不难：

-- 例如，计算订单总价CREATE TABLE orders (quantity INT,unit_price DECIMAL(10,2),total_price DECIMAL(10,2) GENERATED ALWAYS AS (quantity * unit_price) VIRTUAL);

虚拟列还是比较好用的，但是也得注意，不是所有的场景都适合使用，这里先讲适合的。

适合使用虚拟列的场景

1. 可以简化查询和业务操作的，避免在多个查询中重复编写相同的表达式

-- 例如，计算订单总价CREATE TABLE orders (quantity INT,unit_price DECIMAL(10,2),total_price DECIMAL(10,2) GENERATED ALWAYS AS (quantity * unit_price) VIRTUAL);

2. 需要确保计算值始终正确且一致

-- 自动计算年龄CREATE TABLE persons (birth_date DATE,age INT GENERATED ALWAYS AS (YEAR(CURDATE()) - YEAR(birth_date)) VIRTUAL);

3. 从JSON列中提取特定字段或者做一些判断

CREATE TABLE products (attributes JSON,product_name VARCHAR(100) GENERATED ALWAYS AS (attributes->>'$.name') VIRTUAL
);

4. 利用虚拟列创建索引，提高查询性能

这个特性需要MySQL 8.0+

CREATE TABLE users (full_name VARCHAR(100),first_name VARCHAR(50) GENERATED ALWAYS AS (SUBSTRING_INDEX(full_name, ' ', 1)) VIRTUAL,INDEX (first_name));

不适合使用虚拟列的场景

1. 计算成本过高、过于复杂的表达式会影响性能
2. 频繁更新的表，则不适用VIRTUAL列，毕竟在每次查询时都会重新计算
3. 存储空间严重受限时，谨慎使用使用STORED类型时，因为STORED列会增加存储空间
4. MySQL 5.7 以下不支持虚拟列
5. 计算依赖于不确定性函数（如NOW()、RAND()）的，也不能使用

虚拟列的限制

1. 不能在虚拟列中使用子查询
2. 不能引用自增列
3. 不能使用存储函数或用户定义的函数
4. 不能使用不确定函数（如NOW()）
5. 不能将虚拟列作为外键
6. 不能设置默认值

性能考虑

1. VIRTUAL列：查询时计算，适合计算简单、不频繁查询的列
2. STORED列：写入时计算，适合计算复杂、频繁查询的列
3. 索引：只能在STORED列上创建索引（MySQL 8.0+支持在VIRTUAL列上创建索引）

总结

MySQL虚拟列为我们提供了一个优雅的解决方案，可以将部分计算逻辑从应用层转移到数据层，既保证了数据的一致性，又简化了应用层代码。

在我们的订单系统中，目前有不少字段都用上了虚拟列，确实代码会更加清晰，维护成本也有相应降低。

当然，是否使用虚拟列需要根据具体场景来判断。

对于简单的计算逻辑，特别是需要在多处使用的计算结果，虚拟列是个不错的选择。
但对于复杂的业务逻辑，还是建议放在应用层处理为好。

希望这篇文章能帮助大家更好地理解和使用MySQL虚拟列这个实用的特性。

如果你的项目中有类似的场景，不妨尝试一下这个功能，也欢迎使用过的朋友来交流下心得。