MySQL虚拟列实战：从自动计算到高效索引，如何避开新手常见坑？
做MySQL开发，下面这个场景你一定不陌生：
查询时，那些重复出现的计算逻辑——比如用订单单价乘以数量算小计，或者从手机号里截取后四位——不仅让代码变得臃肿，更糟糕的是，不同人写的逻辑万一有个细微差别，bug就悄悄埋下了。更让人头疼的是，我们明明想给这些计算结果建个索引来加速查询，却常常无从下手。
其实，MySQL早就提供了一个优雅的解决方案：虚拟列。它本质上就是给表加上一个“自动计算的公式列”，既不需要你手动维护数据，还能配合索引，大幅提升查询效率。今天，我们就通过具体操作，把虚拟列的两种类型（STORED和VIRTUAL）、它们的用法差异，以及新手最容易踩的几个坑，一次性讲明白。
一、什么是MySQL虚拟列？
所谓虚拟列，顾名思义，就是这个列的值并非来自手动插入，而是根据表中其他列的值计算生成的。这个概念其实很直观，就像你在Excel里设置一个公式列：只需要输入“单价”和“数量”，“小计”那一栏就会自动算出来。MySQL虚拟列的逻辑与此如出一辙，并且有几个核心特点：
首先，你完全无需手动去插入或更新它的值，只要它依赖的列数据发生变化，虚拟列的结果就会自动同步更新。其次，用来定义它的表达式必须是“确定性”的——也就是说，给定相同的输入，必须得到完全相同的输出。这意味着你可以使用字符串拼接、四则运算等，但不能用像NOW()这样每次调用结果都不同的动态函数。最后，它分为STORED和VIRTUAL两种类型，两者的底层机制和适用场景截然不同，这是后面要重点区分的。
二、实操案例
光说不练假把式，我们直接通过创建表和添加列的方式来演示具体用法。
1. 创建表，且表中包含STORED类型的虚拟列
我们先创建一个订单明细表，并直接在其中定义一个STORED类型的虚拟列来计算小计金额：
mysql> CREATE TABLE order_item (
-> id INT PRIMARY KEY AUTO_INCREMENT,
-> order_id INT NOT NULL COMMENT ‘订单ID’,
-> product_id INT NOT NULL COMMENT ‘商品ID’,
-> price DECIMAL(10,2) NOT NULL COMMENT ‘商品单价（元）’,
-> quantity INT NOT NULL COMMENT ‘购买数量’,
-> — STORED虚拟列：小计金额 = 单价 × 数量（确定性运算，适合存储）
-> subtotal DECIMAL(10,2)
-> GENERATED ALWAYS AS (price * quantity)
-> STORED COMMENT ‘小计金额（物理存储）’
-> );
Query OK, 0 rows affected (0.22 sec)表建好后，我们插入几条数据试试：
mysql> INSERT INTO order_item (order_id, product_id, price, quantity)
-> VALUES
-> (1001, 5001, 99.90, 2),
-> (1001, 5002, 159.00, 1),
-> (1002, 5003, 29.90, 5);
Query OK, 3 rows affected (0.08 sec)
Records: 3 Duplicates: 0 Warnings: 0现在来看看表里的内容：
可以看到，我们并没有为 `subtotal` 列赋值，但它已经自动计算并展示了“单价×数量”的结果。
2. 在现有表上加VIRTUAL类型的列
接下来，我们在已有的表上，通过ALTER TABLE语句添加一个VIRTUAL类型的虚拟列，用来计算含税金额（假设税率13%）：
mysql> ALTER TABLE order_item ADD COLUMN
-> tax_subtotal DECIMAL(10,2)
-> GENERATED ALWAYS AS (price * quantity * 1.13) VIRTUAL COMMENT ‘含13%税小计（实时计算）’;
Query OK, 0 rows affected (0.08 sec)
Records: 0 Duplicates: 0 Warnings: 0再次查询，结果如下：
瞧，两种类型的虚拟列都按照定义的规则正常显示出了计算结果。
3. 更新依赖列，看两种虚拟列的同步逻辑
我们来修改ID为1的商品的单价，看看两个虚拟列会如何变化：
mysql> UPDATE order_item SET price = 89.90 WHERE id = 1;
Query OK， 1 row affected， 2 warnings (0.03 sec)
Rows matched: 1 Changed: 1 Warnings: 2再次查询更新后的数据：
很明显，无论是STORED还是VIRTUAL列，都自动同步更新了，完全不需要我们手动干预。当然，它们俩在底层实现这个同步的机制是不同的，这正是理解它们差异的关键。
三、STORED vs VIRTUAL区别
很多朋友对这两种类型感到困惑，其实核心区别就三点：存储方式、性能开销和使用的灵活性。结合上面的例子，我们一张表就能说清楚：
STORED（存储型）：像表中的普通列一样，数据会实际写入磁盘进行物理存储。它的计算发生在数据插入或更新时，是一次性的开销。因此，读取速度极快（因为直接从磁盘读），但会占用额外的存储空间，并且写入或更新数据时会稍慢一些（因为需要计算并存储结果）。它可以像普通列一样创建索引，甚至可以作为主键的一部分。
VIRTUAL（虚拟型）：数据并不实际存储在磁盘上。它的值是在每次查询时，根据表达式动态计算出来的。因此，它的优点是不占用存储空间，且对数据插入和更新操作几乎没有额外性能影响。缺点是，在查询时如果用到它，就需要进行实时计算，会消耗CPU资源。在MySQL 5.7及更早版本，它不能创建索引，但从MySQL 8.0开始，已经支持在VIRTUAL列上创建索引，这大大拓展了它的应用场景。
四、常见踩坑点
虚拟列用起来不难，但确实有几个地方容易出错。结合常见的实践经验，这里有三个要点需要特别警惕。
1. 使用非确定性函数
这是一个高频错误。定义虚拟列时，表达式必须是“确定性”的。像CONCAT、数学运算这些没问题，但CURDATE()、NOW()、RAND()这类每次调用结果都可能变化的“非确定性”函数，是绝对禁止使用的。
比如，曾有人想创建一个自动计算年龄的虚拟列，使用了CURDATE()，结果直接报错：
— 错误示例：使用了非确定性函数CURDATE()
age INT GENERATED ALWAYS AS (TIMESTAMPDIFF(YEAR, birth_date, CURDATE())) STORED;
— 报错：ERROR 3763 (HY000)： Expression of generated column ‘age’ contains a disallowed function： curdate.对于年龄这种随时间变化的值，正确的做法是在查询时实时计算，而不是试图用虚拟列一劳永逸。
2. 虚拟列依赖其他表的列
虚拟列的计算逻辑，只能依赖本表的其他列。它不能通过子查询去引用其他表的数据，也不能调用存储过程，否则系统会直接拒绝。
3. VIRTUAL类型不能当主键/唯一键
MySQL明确限制，VIRTUAL类型的虚拟列不能作为主键或唯一键的组成部分。因为它的值在事务提交前可能是不确定的。但是，STORED类型的虚拟列在这方面和普通列没有区别，完全可以用于定义主键或唯一约束。
那么，在实际项目中到底该怎么选呢？这里有一个非常直接的决策原则供你参考：
优先考虑VIRTUAL类型：在大多数场景下，VIRTUAL列已经足够好用。它不占磁盘，灵活性高，更新数据时没有额外开销。况且，MySQL 8.0+已经支持为其创建索引来优化查询性能。
仅在特定场景选用STORED：当计算逻辑极其复杂（比如涉及多列深度嵌套运算）、且该列被查询的频率极高（比如核心业务表每秒上千次查询）、同时数据更新频率极低时（比如商品的基础信息表），可以考虑用STORED列，以空间换时间。
务必避免过度使用：虚拟列虽好，但也不是银弹。VIRTUAL列会增加查询时的CPU计算开销，STORED列则会占用额外的存储空间。对于那些并非必要、或者在应用层处理更简单的计算逻辑，不要强行使用虚拟列。
五、总结
总而言之，MySQL虚拟列的核心价值，在于它能帮助我们简化重复的数据计算逻辑，并有机会通过索引来大幅提升查询效率。STORED类型是经典的“空间换时间”，而VIRTUAL类型则是“时间换空间”的灵活代表。
最后记住这几个关键结论：当你的计算逻辑是确定性的，且需要在多个查询中重复使用时，虚拟列就是一个值得考虑的利器。选择时，优先考虑VIRTUAL，特殊场景再用STORED。一定要避开使用非确定性函数的坑，并且时刻提醒自己：如非必要，勿增实体，不要为了用而用。
