STORED虚拟列占用磁盘空间，写入时计算并持久化；VIRTUAL列不占空间但每次查询重算，且仅STORED列支持普通索引，VIRTUAL需函数索引，二者性能权衡取决于写时还是读时计算及索引覆盖能力。
STORED 虚拟列实际占用磁盘空间
MySQL 的 STORED 虚拟列会在写入时计算并持久化到磁盘，和普通列一样参与行存储。这意味着每行数据体积增大，InnoDB 页内能存放的记录数减少，可能引发更多页分裂或 I/O。尤其当表达式涉及大字段（如 SUBSTRING(long_text, 1, 100)）或函数返回长结果时，空间开销明显。可通过 INFORMATION_SCHEMA.COLUMNS 查看 EXTRA 字段确认是否为 STORED，再用 SHOW TABLE STATUS 观察 Data_length 变化验证实际增长。
VIRTUAL 虚拟列不存数据但每次查询都重算
VIRTUAL 列只保存表达式定义，查询时实时计算，不占磁盘空间，也不参与主键/外键约束（除非显式声明 STORED）。但代价是：每次 SELECT 涉及该列，或 WHERE/ORDER BY 使用它，都会触发函数调用。例如 WHERE YEAR(created_at) = 2024 在 VIRTUAL 列上执行，等于对每行调用一次 YEAR()；若表有千万级数据且无函数索引支持，性能会陡降。注意：MySQL 5.7+ 对 VIRTUAL 列支持函数索引，但索引本身仍需额外空间。
索引能力与执行计划差异明显
只有 STORED 列能被直接用于普通 B+ 树索引（包括前缀索引），VIRTUAL 列必须配合函数索引（如 INDEX idx_year ((YEAR(created_at)))）才能加速查询。但函数索引有局限：
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 仅支持确定性函数（如
UPPER()、YEAR()），RAND()或NOW()类非确定性函数不允许 - 优化器有时无法准确估算选择率，导致错误选择全表扫描
-
VIRTUAL列上的ORDER BY无法利用索引排序，必然触发 filesort
EXPLAIN 观察 key 和 Extra 字段可快速判断是否命中索引。
写入性能：STORED 拖慢 INSERT/UPDATE，VIRTUAL 几乎无影响
STORED 列在 INSERT 或 UPDATE 时强制计算并写入，如果表达式复杂（如嵌套 JSON 函数、正则匹配 REGEXP_SUBSTR()），会显著拉高单条语句延迟。而 VIRTUAL 列完全跳过这一步，写入吞吐更稳定。不过要注意：如果业务频繁更新基础列（如 created_at），又依赖 STORED 衍生列做查询过滤，可能因索引失效或 MVCC 版本链变长间接拖慢读性能。
真正关键的权衡点不在“快”或“省”，而在于你能否接受写时计算（STORED）还是读时计算（VIRTUAL）——以及这个计算是否可被索引覆盖。很多线上事故源于把高计算量表达式设为 STORED 后未压测写入，或把高频过滤字段设为 VIRTUAL 却忘了建函数索引。
