MySQL 5.7 的 JSON 查询本身不慢，但无法为 JSON 路径建函数索引，必须用 STORED 生成列间接索引；8.0 支持原生函数索引（如 ((data->>'$.status'))），无需额外存储且真正加速查询。
MySQL 5.7 的 JSON 查询不是“慢”，而是根本没走索引加速路径——它压根不支持对 JSON 路径表达式建函数索引，所有 ->> 或 JSON_EXTRACT() 都强制全表扫描。
5.7 无法为 JSON 路径创建有效索引
5.7 虽然支持 JSON 类型和提取函数，但优化器完全无法将 data->>'$.status' 这类表达式映射到 B+ 树索引上。即使你建了生成列，也必须满足两个硬性条件才可能生效：
- 生成列必须是
STORED类型（VIRTUAL列在 5.7 中不可索引） - 生成列的表达式必须严格匹配查询中使用的路径和函数，比如
JSON_UNQUOTE(JSON_EXTRACT(data, '$.status'))和data->>'$.status'在语义上等价，但 5.7 优化器不识别这种等价性，索引不会被选中 - 一旦查询里出现任何函数包装（如
UPPER(data->>'$.status')），整个路径就彻底脱离索引能力范围
8.0 引入函数索引，让 JSON 路径真正可索引
MySQL 8.0 开始支持直接在函数表达式上建索引，这是质变。你可以这样写：
CREATE INDEX idx_user_status ON users ((data->>'$.status'));
注意括号里的双层括号：外层是语法要求，内层才是表达式本身。这条语句在 8.0 中会真实创建一个 B+ 树索引，内容是每个 data 字段解析后 $.status 的字符串值。执行 WHERE data->>'$.status' = 'active' 时，EXPLAIN 显示 type: ref、key: idx_user_status，不再是 type: all。
关键区别在于：
- 5.7 的生成列索引是“间接绕路”，且写放大明显；8.0 的函数索引是“原生支持”，无额外存储开销
- 8.0 的函数索引支持多字段组合，例如
((data->>'$.env'), (data->>'$.region'))，能覆盖更复杂的 JSON 查询场景 - 但要注意：函数索引只对确定性表达式生效；含
NOW()、RAND()或用户变量的表达式无法建函数索引
JSON 解析开销在 5.7 和 8.0 中的差异被严重低估
很多人以为“只是没索引，解析快一点就行”，实际上 JSON 解析本身在两个版本间成本差异巨大：
- 5.7 的 JSON 解析器较轻量，仅做 RFC 7159 基础校验，但每次
->>都要重新解析整段 JSON 文本（哪怕只取一个字段） - 8.0 默认启用更严格的 UTF8MB4 完整性校验 + Unicode 代理对检查 + 深度嵌套预解析，单次
->>开销更高，但配合函数索引后，实际执行时只需解析命中行，总体耗时反而大幅下降 - 如果你在 5.7 上靠应用层缓存 JSON 字段再本地解析，有时比数据库内解析更快；但在 8.0 上，只要索引到位，数据库内解析 + 索引过滤的组合效率远超应用层搬运
升级后仍慢？先确认是否真用了函数索引
很多团队升级到 8.0 后没重跑 DDL，还在用 5.7 那套生成列方案，结果性能毫无改善。验证方法很简单：
- 执行
SHOW CREATE TABLE users;，确认索引定义里是否含((data->>'$.status'))这样的双括号结构 - 执行
EXPLAIN SELECT * FROM users WHERE data->>'$.status' = 'active';，看key列是否显示你的函数索引名，且rows值远小于表总行数 - 如果
Extra出现Using where; Using filesort，大概率是排序字段未被覆盖，或sort_buffer_size不足触发磁盘排序——这和 JSON 本身无关，但常被误判
最易被忽略的一点：函数索引对大小写敏感，data->>'$.Status' 和 data->>'$.status' 是两个完全不同的表达式，索引无法复用。路径字符串必须字面量一致。
