VIRTUAL列不占磁盘空间但每次查询实时计算，无法索引加速；STORED列写入磁盘、支持索引和约束，但增加写开销与存储成本。选VIRTUAL适用于低频读、高写压场景；必须用STORED当需WHERE过滤、唯一约束或兼容旧版本。
虚拟列 VIRTUAL 不会写入磁盘，但每次查询都要实时计算
MySQL 的 VIRTUAL 列不占用表的物理存储空间，它的值在 SELECT 时才通过定义的表达式动态计算。这意味着：如果表达式涉及多表 JOIN、子查询或函数（如 JSON_EXTRACT()、CONCAT()），每次读取该列都会触发完整计算，无法利用索引加速（除非是生成列 + 索引的组合，且 MySQL 5.7+ 支持对 STORED 列建索引）。
常见踩坑点：
-
VIRTUAL列不能被WHERE条件直接高效过滤——除非你额外在该列上创建函数索引（MySQL 8.0.13+）或改用STORED - 触发器或
INSERT ... SELECT中引用VIRTUAL列，可能因上下文缺失导致NULL或报错（比如依赖未插入的其他字段） - 备份恢复时不会丢失，但主从复制中若从库版本低（如 5.6），不识别
VIRTUAL语法，会直接报错建表失败
STORED 列写入磁盘，支持索引但增加写开销和存储成本
STORED 列的值在 INSERT 或 UPDATE 时就计算并持久化到磁盘，后续查询直接读取，不重复计算。它支持普通索引、唯一约束、外键（仅限 InnoDB，且要求确定性表达式），适合高频读、低频写的场景。
关键权衡点：
- 写入变慢：每个
INSERT/UPDATE都要多算一次表达式，并写入额外字段；若表达式复杂（如嵌套REGEXP_SUBSTR），延迟明显上升 - 存储膨胀：每行多存一个字段值，尤其类型为
TEXT或长VARCHAR时，BLOB/TEXT 类型还会额外占用指针空间 - 主从一致性更强：因为值已固化，不依赖从库运行时环境（如函数是否存在、时区设置等）
什么时候该选 VIRTUAL，什么时候必须用 STORED
判断依据不是“想不想存”，而是“查得多不多”和“能不能接受写放大”。
推荐选 VIRTUAL 的情况：
- 只在报表导出或后台管理页偶尔展示，且表达式轻量（如
price * quantity） - 字段用于 JSON 解析后临时取值（如
JSON_UNQUOTE(JSON_EXTRACT(metadata, '$.status'))），但业务层本身不按它筛选 - 表写入压力极大（如每秒数千 INSERT），且磁盘空间敏感（如云数据库按存储计费）
必须用 STORED 的情况：
- 需要在
WHERE、ORDER BY或GROUP BY中频繁使用该列（例如提取日期段做分区裁剪） - 要对该列加唯一约束（如确保邮箱小写化后唯一：
email_lower VARCHAR(255) AS (LOWER(email)) STORED UNIQUE） - 使用了 MySQL 5.7 之前的版本——
VIRTUAL不被支持，只能用STORED（或放弃生成列）
真实性能差异：一个 SUBSTRING_INDEX(url, '/', 3) 场景测试参考
在千万级日志表上，对 URL 字段提取协议+域名部分：
url_host VARCHAR(255) AS (SUBSTRING_INDEX(url, '/', 3)) STORED
对比 VIRTUAL 版本：
- 写入吞吐下降约 12%（InnoDB buffer pool 压力略增，redo log 多写约 40 字节/行）
- 全表扫描下，
STORED查询快 3.2 倍（避免重复解析字符串） - 加了索引后，
WHERE url_host = 'https://example.com'查询，STORED走索引，VIRTUAL只能全表扫描（无函数索引支持时） - 磁盘占用多出约 2.1 GB（按平均长度 22 字节 × 行数估算）
真正难决策的，往往不是读写比，而是表达式是否稳定——比如调用自定义函数或依赖系统变量的生成列，在主从或备份还原时容易静默失败，这类必须砍掉或强转为应用层处理。
