虚拟列必须用 GENERATED ALWAYS AS 显式声明类型，且表达式结果须严格匹配；VIRTUAL 适合写多读少场景，STORED 适合读多写少并支持更多索引约束；虚拟列索引本质是普通列索引，需联合索引覆盖查询字段才能免回表。
虚拟列必须用 GENERATED ALWAYS AS 定义，且类型要显式声明
MySQL 不允许虚拟列类型由表达式自动推断，GENERATED ALWAYS AS 后的表达式结果必须匹配你声明的列类型，否则建表或加列会失败。比如从 created_at TIMESTAMP 提取年份，不能只写 TINYINT 就完事——YEAR(created_at) 返回 4 位整数（如 2026），超出 TINYINT 范围（-128~127），得用 SMALLINT 或 YEAR 类型。
常见错误现象：ERROR 3105 (HY000): The value specified for generated column 'year_created' is not allowed，基本就是类型不兼容或表达式非确定性导致的。
- 日期类推荐用
YEAR或SMALLINT，别用TINYINT - 字符串截取如
SUBSTRING_INDEX(email, '@', -1)必须配VARCHAR(N)，N 至少大于域名平均长度 - JSON 提取字段如
JSON_EXTRACT(data, '$.status')需配合CAST(... AS CHAR)显式转类型，否则无法建索引
VIRTUAL 列 + 二级索引是默认组合，但 STORED 更适合高频读+低频写场景
VIRTUAL 虚拟列不存数据，每次查询都实时计算，适合计算轻量、写入频繁的场景；STORED 则在 INSERT/UPDATE 时就计算并落盘，读快但写有开销。两者都能建索引，但 STORED 支持主键、唯一约束、外键等更全的索引能力。
性能影响很实际：如果你的表达式涉及 JSON_EXTRACT + 多层嵌套 + CAST，用 VIRTUAL 可能让单条 SELECT 增加 0.5~2ms CPU 计算时间；换成 STORED 后，INSERT 延迟可能从 0.3ms 升到 1.1ms——得看你的读写比。
- 日志类、订单类表（写多读少）：优先
VIRTUAL - 用户资料、配置类表（读远多于写）：考虑
STORED - 别在
VIRTUAL列上建唯一索引——MySQL 不允许
函数索引和虚拟列索引不是一回事，别混用
MySQL 8.0 的函数索引（如 CREATE INDEX idx ON t ((UPPER(name)))）和虚拟列索引（如 ADD COLUMN name_upper VARCHAR(50) GENERATED ALWAYS AS (UPPER(name)) VIRTUAL）底层机制不同：前者是优化器对表达式的直接识别，后者是真实列对象。它们互不替代，也互不兼容。
关键区别在于匹配粒度：((UPPER(name))) 索引只响应字面完全一致的 WHERE UPPER(name) = 'JOHN'；而虚拟列一旦建好，你可以对 name_upper 做任意操作——LIKE 'JO%'、IN ('JOHN','JANE')、甚至再套一层 LENGTH(name_upper) > 3，只要该列本身有索引，就能走。
- 函数索引不能用于模糊查询（
LIKE左通配）、范围比较（>）、OR分支 - 虚拟列索引本质是普通列索引，支持所有常规操作，包括前缀索引、联合索引、覆盖索引
- 如果已有函数索引但查询模式变复杂了，不如直接切到虚拟列方案
EXPLAIN 里 key 字段有值 ≠ 真走索引，务必确认 Extra 是否含 Using index
加了虚拟列索引后，EXPLAIN 显示 key 列非空，只能说明优化器选了这个索引；真正决定是否免回表的是 Extra 字段是否出现 Using index。如果没出现，说明虽然用了索引定位行，但 SELECT 的字段不在索引里，还得回聚簇索引捞数据。
容易被忽略的点：虚拟列本身是计算出来的，但它的索引结构和普通列一样——也就是说，想实现覆盖，你得把虚拟列和其他需要的字段一起放进联合索引，而不是只给虚拟列单独建索引。
- 错例：只建
ADD INDEX idx_status (status_upper)，然后查SELECT id, status_upper FROM t WHERE status_upper = 'ACTIVE'→ 回表 - 对例：建
ADD INDEX idx_cover (status_upper, id)→Extra: Using index - 虚拟列参与联合索引时，顺序仍要服从最左前缀原则；布尔条件字段（如
!=）尽量放最左
