MySQL 虚拟列（VIRTUAL / STORED）在查询与插入时的性能差异

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

虚拟列不是语法糖，是把计算责任从查询侧转移到写入侧（或反之）的明确契约。选错类型，轻则慢查询，重则阻塞写入或破坏数据完整性。