mysql 5.7 的 json 查询必须依赖 stored 生成列，因其不支持函数索引，json_extract() 等表达式无法直接建索引，只能通过 stored 列+普通索引实现加速；而 mysql 8.0 支持函数索引，可直接在表达式上建索引，无需生成列。
MySQL 5.7 的 JSON 查询为什么必须依赖 STORED 生成列
因为 5.7 不支持函数索引，JSON_EXTRACT() 这类表达式无法直接建索引。你写 WHERE JSON_EXTRACT(data, '$.id') = 123，MySQL 只能全表扫描并逐行解析 JSON 字符串——哪怕字段定义为 JSON 类型，也毫无加速作用。
唯一可行路径是：先用 AS 定义一个生成列，再确保它是 STORED（不是 VIRTUAL），最后在该列上建普通索引。否则索引根本不会被创建或使用。
-
VIRTUAL列在 5.7 中不可索引，建索引会静默失败或报错ERROR 3105 - 生成列的类型必须匹配提取结果，比如
JSON_EXTRACT(j, '$.user_id')返回 JSON 类型值，比较时隐式转字符串，但若想走索引，应显式用JSON_UNQUOTE()转成VARCHAR或UNSIGNED INT - 字段定义里没加
NOT NULL，会导致生成列值可能为NULL，影响索引选择率，查询优化器更倾向全表扫
为什么 MySQL 8.0 不再需要三步建索引
8.0 支持函数索引，语法就是直接在 CREATE INDEX 里写表达式：CREATE INDEX idx_user_id ON users ( (JSON_EXTRACT(profile, '$.user_id')) )。括号包裹的表达式即“函数索引”，底层自动处理确定性校验、类型推导和索引构建，无需人工中转列。
这不只是语法糖——它消除了 STORED 列带来的写放大和存储冗余。每次更新 profile 字段，5.7 必须重算并落盘生成列；8.0 的函数索引只存表达式结果的索引项，不额外存物理列。
- 函数索引要求表达式是
DETERMINISTIC，JSON_EXTRACT()满足，但NOW()、RAND()不行 - 索引长度仍受
innodb_page_size和innodb_large_prefix限制，超长路径如'$.metadata.tags[*].name'可能截断，导致索引失效 - 升级后若沿用 5.7 的
STORED列，要记得删掉——它们已无存在必要，反而占空间、拖慢 DML
常见错误：建了生成列却没走索引
即使你按规范在 5.7 建了 STORED 列和索引，查询仍可能不走索引，原因很具体：
- SQL 中没引用该生成列，还在原 JSON 字段上写
JSON_CONTAINS()或->操作符 - 生成列用了
VIRTUAL，但你误以为它可索引（5.7 不行，8.0 也不行） - 字符集或排序规则不一致：比如生成列为
VARCHAR(50)用utf8mb4_0900_as_cs，而查询条件用的是utf8mb4_general_ci，触发隐式转换，索引失效 -
EXPLAIN显示key为空，且Extra含Using where而非Using index，说明索引未命中
真实性能瓶颈往往不在函数本身
测试显示 8.0 的 JSON_EXTRACT() 单次调用比 5.7 快 15%–35%，但这数字只有在索引已生效、数据结构简单、路径无通配符时才成立。一旦查询没走索引，两者都会退化为全表 JSON 解析，差异几乎为零。
真正卡住性能的，是你有没有把 JSON 字段当「需要索引的业务字段」来设计——而不是当成「存完就不管的 blob」。5.7 强制你显式暴露这个决策（建列 → 建索引），8.0 把它简化为一步，但逻辑没变：不索引，就别指望快。
