MySQL虚拟列：一个被低估的MySQL特性
前言
最近在做订单系统重构时，遇到了一个有趣的问题。
系统里有很多地方都要计算订单的总价（数量×单价），这个计算逻辑分散在各个服务中，产生了不少相似甚至重复的代码。
代码评审时，同事提出了一个建议 —— 使用MySQL的虚拟列来统一处理这类计算，在调研后我们一致决定采纳。
经过一段时间的生产实践，也逐渐摸清了虚拟列的套路，这里就和大家分享一下这个特性的使用心得。
耐心看完，你一定有所收获。
MySQL 5.7版本引入的虚拟列（Generated Columns）允许我们定义一个基于其他列计算得出的列。
它有点像Excel中的计算列，但更加强大和灵活。
虚拟列分为两种类型：
- VIRTUAL（虚拟列）：在读取时实时计算，不占用存储空间
- STORED（存储列）：在数据写入时计算并存储，会占用实际存储空间
基本语法
创建虚拟列的语法不难：
-- 例如，计算订单总价CREATE TABLE orders (quantity INT,unit_price DECIMAL(10,2),total_price DECIMAL(10,2) GENERATED ALWAYS AS (quantity * unit_price) VIRTUAL);
虚拟列还是比较好用的，但是也得注意，不是所有的场景都适合使用，这里先讲适合的。
适合使用虚拟列的场景
- 可以简化查询和业务操作的，避免在多个查询中重复编写相同的表达式
-- 例如，计算订单总价CREATE TABLE orders (quantity INT,unit_price DECIMAL(10,2),total_price DECIMAL(10,2) GENERATED ALWAYS AS (quantity * unit_price) VIRTUAL);- 需要确保计算值始终正确且一致
-- 自动计算年龄CREATE TABLE persons (birth_date DATE,age INT GENERATED ALWAYS AS (YEAR(CURDATE()) - YEAR(birth_date)) VIRTUAL);- 从JSON列中提取特定字段或者做一些判断
CREATE TABLE products (attributes JSON,product_name VARCHAR(100) GENERATED ALWAYS AS (attributes->>'$.name') VIRTUAL
);- 利用虚拟列创建索引，提高查询性能
这个特性需要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));
不适合使用虚拟列的场景
- 计算成本过高、过于复杂的表达式会影响性能
- 频繁更新的表，则不适用VIRTUAL列，毕竟在每次查询时都会重新计算
- 存储空间严重受限时，谨慎使用使用STORED类型时，因为STORED列会增加存储空间
- MySQL 5.7 以下不支持虚拟列
- 计算依赖于不确定性函数（如NOW()、RAND()）的，也不能使用
虚拟列的限制
- 不能在虚拟列中使用子查询
- 不能引用自增列
- 不能使用存储函数或用户定义的函数
- 不能使用不确定函数（如NOW()）
- 不能将虚拟列作为外键
- 不能设置默认值
性能考虑
- VIRTUAL列：查询时计算，适合计算简单、不频繁查询的列
- STORED列：写入时计算，适合计算复杂、频繁查询的列
- 索引：只能在STORED列上创建索引（MySQL 8.0+支持在VIRTUAL列上创建索引）
总结
MySQL虚拟列为我们提供了一个优雅的解决方案，可以将部分计算逻辑从应用层转移到数据层，既保证了数据的一致性，又简化了应用层代码。
在我们的订单系统中，目前有不少字段都用上了虚拟列，确实代码会更加清晰，维护成本也有相应降低。
当然，是否使用虚拟列需要根据具体场景来判断。
对于简单的计算逻辑，特别是需要在多处使用的计算结果，虚拟列是个不错的选择。
但对于复杂的业务逻辑，还是建议放在应用层处理为好。
希望这篇文章能帮助大家更好地理解和使用MySQL虚拟列这个实用的特性。
如果你的项目中有类似的场景，不妨尝试一下这个功能，也欢迎使用过的朋友来交流下心得。