虚拟列索引通过将函数结果固化为新列并建索引，使where条件直接匹配预计算值，避免运行时计算导致的索引失效；需用stored类型+显式类型声明，查询必须引用虚拟列而非原表达式。
为什么虚拟列索引能绕过函数导致的索引失效
直接在 WHERE 条件里用函数（比如 DATE_FORMAT(created_at, '%Y-%m') 或 LOWER(name)）时，MySQL 无法复用原始列上的索引，因为索引里存的是原始值，不是函数结果。优化器只能全表扫描——哪怕你给 created_at 或 name 单独建了索引也没用。
虚拟列索引的本质是：把函数计算结果“固化”成一列，再对这列建索引。它不改变原表语义，但让查询条件从「运行时计算」变成「查预计算值」，执行计划里 type 就能从 ALL 变成 ref 或 range。
注意：虚拟列本身不占磁盘空间（VIRTUAL 类型），但它的索引要存数据，所以索引大小 ≈ 函数结果值的总长度 × 行数。
创建虚拟列 + 索引的三步实操
以订单表按年月归档查询为例（高频场景：后台导出 2024-09 的全部订单）：
- 先加虚拟列：
ALTER TABLE orders ADD COLUMN ym CHAR(7) AS (DATE_FORMAT(created_at, '%Y-%m')) STORED;（用STORED而非VIRTUAL，避免每次查询都重复计算） - 再建索引：
CREATE INDEX idx_orders_ym ON orders(ym); - 改写查询：
SELECT * FROM orders WHERE ym = '2024-09';（必须直接查虚拟列，不能写WHERE DATE_FORMAT(created_at, '%Y-%m') = '2024-09'）
如果已有千万级数据，STORED 列的首次添加会锁表并触发全量计算，建议在低峰期执行；VIRTUAL 则无此开销，但高并发查询时 CPU 压力会上升。
JSON 字段提取值的虚拟列索引怎么写才不踩坑
针对 extra JSON 里频繁查 $.user_level 的场景，不能直接对 extra->>'$.user_level' 建索引（5.7 不支持，8.0 函数索引也不接受 JSON 提取表达式）。
正确做法是显式定义虚拟列：
ALTER TABLE orders ADD COLUMN user_level TINYINT UNSIGNED AS (extra->>'$.user_level') STORED;CREATE INDEX idx_orders_user_level ON orders(user_level);- 查询必须用：
SELECT * FROM orders WHERE user_level = 3;（不能写WHERE extra->>'$.user_level' = 3）
关键细节：->> 返回的是字符串，所以虚拟列类型要显式声明为数值型（如 TINYINT），否则索引会按字符串排序（'10' user_level = 3 会漏掉真实值为 3 的行。
函数索引 vs 显式虚拟列：选哪个更稳
MySQL 8.0.13+ 支持函数索引（CREATE INDEX idx ON t((DATE_FORMAT(dt, '%Y')))），看起来更简洁。但它有隐藏约束：
- 函数索引内部依赖隐式虚拟列，但你无法控制该列是否
STORED；实测某些复杂表达式（含JSON_EXTRACT、嵌套CASE）会导致隐式列计算失败，建索引直接报错 - 函数索引不支持
DESC排序（如ORDER BY DATE_FORMAT(dt, '%Y') DESC仍可能触发 filesort） - 显式虚拟列可随时
EXPLAIN查看其值，便于验证数据一致性；函数索引则黑盒化，排查困难
生产环境建议优先用显式 STORED 虚拟列 + 普通索引：可控、可测、兼容性好，升级到 8.0 后也不用重构。
最易被忽略的一点：虚拟列的表达式必须是确定性的（same input → same output），像 NOW()、RAND()、USER() 这类函数不能用于虚拟列定义，否则建表会失败。
