MySQL虚拟列：一个被低估的MySQL特性

前言

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

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

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

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

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

正文

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

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

虚拟列分为两种类型：

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

基本语法

创建虚拟列的语法不难：

sql 复制代码

CREATE TABLE orders (
  quantity INT,
  unit_price DECIMAL(10,2),
  total_price DECIMAL(10,2) GENERATED ALWAYS AS (quantity * unit_price) VIRTUAL
);

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

适合使用虚拟列的场景

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

sql 复制代码

-- 例如，计算订单总价

CREATE TABLE orders (

  quantity INT,

  unit_price DECIMAL(10,2),

  total_price DECIMAL(10,2) GENERATED ALWAYS AS (quantity * unit_price) VIRTUAL

);

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

sql 复制代码

-- 自动计算年龄

CREATE TABLE persons (

  birth_date DATE,

  age INT GENERATED ALWAYS AS (YEAR(CURDATE()) - YEAR(birth_date)) VIRTUAL

);

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

sql 复制代码

CREATE TABLE products (

  attributes JSON,

  product_name VARCHAR(100) GENERATED ALWAYS AS (attributes->>'$.name') VIRTUAL

);

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

这个特性需要MySQL 8.0+

scss 复制代码

```sql

CREATE TABLE users (

  full_name VARCHAR(100),

  first_name VARCHAR(50) GENERATED ALWAYS AS (SUBSTRING_INDEX(full_name, ' ', 1)) VIRTUAL,

  INDEX (first_name)

);
```

不适合使用虚拟列的场景

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

虚拟列的限制

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

性能考虑

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

结尾

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

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

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

对于简单的计算逻辑，特别是需要在多处使用的计算结果，虚拟列是个不错的选择。

但对于复杂的业务逻辑，还是建议放在应用层处理为好。

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

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