能，但仅限确定性、无副作用表达式；如price*quantity可行，而NOW()、UUID()、子查询等会报ERROR 3105。
虚拟列能替代应用层计算吗
能，但只适合确定性、无副作用的表达式。比如 price * quantity 这种纯数学运算可以放心扔给 MySQL 做，但涉及 NOW()、UUID()、子查询或用户变量就不行——MySQL 会直接报错 ERROR 3105 (HY000): Expression of generated column ... cannot refer to a non-deterministic function。
常见错误现象：建表时加了 AS (RAND()) 或 AS (SELECT COUNT(*) FROM logs)，结果 DDL 失败；或者用 STORED 虚拟列却依赖了未定义的列（顺序错乱）。
- 必须确保表达式中所有引用列已声明在该列之前（建表时顺序敏感）
-
VIRTUAL列不占磁盘空间，但每次读取都实时计算；STORED列写入时计算并持久化，支持索引但增加写开销 - 如果字段要用于
WHERE或ORDER BY，优先选STORED并显式加索引，否则优化器大概率不走索引
JSON 字段里提取值后做虚拟列还有效吗
有效，但要注意函数兼容性和索引限制。MySQL 5.7+ 支持用 JSON_EXTRACT() 或简写操作符 -> 和 ->> 构造虚拟列，例如 user_data->>"$.age" 可生成一个整型虚拟列。
问题常出在类型转换上：JSON 中的 "123" 是字符串，直接 ->"$.age" 得到的是 JSON 类型，无法参与数值比较；必须用 ->>"$.age"（带双引号）触发自动类型转换，或显式套 CAST(... AS UNSIGNED)。
- 虚拟列定义里不能用
JSON_CONTAINS()这类返回布尔的函数（MySQL 不支持 BOOLEAN 类型作为列类型） -
STORED模式下，JSON 路径表达式必须是常量字面量，不能拼接变量或列名 - 即使建好了虚拟列，
WHERE json_age > 18也未必走索引——得确认执行计划里key字段真有对应索引名
ALTER TABLE 添加虚拟列会影响线上表吗
影响程度取决于模式：VIRTUAL 列几乎无感，STORED 列在 MySQL 5.7 中会锁表重写全量数据，8.0+ 改为在线 DDL，但仍可能触发二级索引重建和缓冲池压力飙升。
典型卡点：给千万级订单表加 total_amount STORED AS (price * qty + fee)，没加 ALGORITHM=INPLACE 提示，结果 ALTER 卡住 20 分钟，主从延迟爆表。
- 务必在低峰期操作，并提前在从库验证耗时
- 加
STORED列前检查磁盘剩余空间——临时文件可能膨胀到原表 2 倍大小 - 若只是临时调试，优先用
VIRTUAL+ 应用层缓存，别急着落库
虚拟列和函数索引有什么区别
本质不同：虚拟列是真实列（哪怕 VIRTUAL），可被 SELECT、JOIN、GROUP BY 直接引用；函数索引（MySQL 8.0.13+）只是索引结构，不提供新字段，也不能出现在 SELECT 列表里。
比如想按邮箱域名分组统计，CREATE INDEX idx_domain ON users ((SUBSTRING_INDEX(email, '@', -1))) 能加速 WHERE email LIKE '%@gmail.com'，但你没法 SELECT SUBSTRING_INDEX(email, '@', -1) AS domain——除非额外建个虚拟列。
- 函数索引不支持
JSON函数、窗口函数、存储过程调用 - 虚拟列支持更广的表达式范围，但占用更多元数据管理成本
- 两者不互斥：可以先建虚拟列，再对它建普通索引，效果通常比函数索引更稳定
最易忽略的一点：虚拟列的表达式在 INSERT/UPDATE 时由服务端计算，如果应用层同时也在算同一逻辑，两边小数精度、时区、字符集处理稍有差异，数据就对不上。上线前一定拿真实业务数据跑一遍一致性校验。
