VIRTUAL列插入时不计算不存储，仅解析时跳过；STORED列插入时实时计算并写入磁盘，影响写入性能但支持索引与约束。
虚拟列在 INSERT 时到底做了什么
MySQL 的 VIRTUAL 列在插入时不存储、不计算，只是在语句解析阶段被跳过；而 STORED 列会在 INSERT 或 UPDATE 时实时计算并写入磁盘。这意味着：
-
VIRTUAL列对写入性能几乎无影响，无论表达式多复杂（比如嵌套函数、子查询）都不会拖慢插入 -
STORED列的表达式会在每一行写入时执行一次，若含SUBSTRING_INDEX()、JSON_EXTRACT()或自定义函数，可能显著增加 CPU 开销 - 如果表达式引用了其他列但该列值为
NULL，STORED列会提前报错（如触发ERROR 1048），而VIRTUAL列不会——它只在 SELECT 时才真正求值
SELECT 查询时的执行计划差异
VIRTUAL 列无法被索引，每次查询都需重新计算；STORED 列可建索引，且优化器能像普通列一样使用它做 range scan 或 index lookup。
- 用
EXPLAIN查看执行计划时，若 WHERE 条件含VIRTUAL列，通常显示type: ALL（全表扫描），因为无法走索引 -
STORED列加了索引后，WHERE status = 'active'可命中索引，哪怕status是由CASE WHEN order_total > 100 THEN 'active' ELSE 'pending' END定义的 - 注意：即使
STORED列有索引，如果表达式里用了不可下推的函数（如NOW()、RAND()），MySQL 会拒绝创建列或报错ERROR 3105
什么时候必须用 STORED，什么时候死守 VIRTUAL
选型关键不在“要不要存”，而在“谁来承担计算成本”和“是否需要索引/约束”。
- 必须用
STORED：要对该列建唯一约束、主键、外键，或需要在 WHERE / ORDER BY 中高频过滤/排序且数据量大 - 必须用
VIRTUAL：表达式依赖运行时上下文（如USER()、CURRENT_TIMESTAMP），或仅用于报表类 SELECT，且写入压力敏感（如日志表每秒万级 INSERT） - 容易踩坑的是混合场景：比如用
VIRTUAL列做GROUP BY，数据量一过百万，CPU 就飙升——这时不是换STORED就能解决，得配合物化视图或冗余字段
实际建表时的参数陷阱
声明虚拟列时，类型、长度、是否允许 NULL 这些看似无关的细节，直接影响行为一致性。
-
VIRTUAL列的类型必须显式指定，且不能比表达式实际结果更宽（如表达式返回TINYINT，却定义为INT，可能隐式截断） -
STORED列若定义为NOT NULL，但表达式结果可能为NULL（比如JSON_EXTRACT(json_col, '$.name')在字段缺失时返回NULL），INSERT 会直接失败 - 所有虚拟列都不支持 DEFAULT 值，也不参与
INSERT INTO ... SELECT *的自动匹配——漏掉显式列出，就会报ERROR 1136
