MySQL 5.7 的 JSON 查询不走索引，因不支持函数索引，仅 STORED 生成列且表达式完全一致时才可能生效；8.0 支持原生函数索引，可直接对 data->>'$.status' 建索引，解析开销虽高但配合索引后总体性能更优。
MySQL 5.7 的 JSON 查询不是“慢”，而是根本没走索引——它压根不支持对 data->>'$.status' 这类表达式建函数索引，所有查询都强制全表扫描。
5.7 无法为 JSON 路径创建有效索引
你写 WHERE data->>'$.status' = 'active'，5.7 优化器完全无法把它映射到 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'));
注意双层括号：外层是语法要求，内层才是表达式本身。这条语句会真实创建一个 B+ 树索引，内容就是每个 data 字段解析后 $.status 的字符串值。执行时 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 中差异被严重低估
很多人以为“只是没索引，解析快一点就行”，实际上解析成本本身就有巨大差异：
- 5.7 的 JSON 解析器较轻量，但每次
->>都要重新解析整段 JSON 文本（哪怕只取一个字段） - 8.0 默认启用更严格的 UTF8MB4 完整性校验 + Unicode 代理对检查 + 深度嵌套预解析，单次
->>开销更高 - 但配合函数索引后，实际执行时只需解析命中行，总体耗时反而大幅下降
- 如果你在 5.7 上靠应用层缓存 JSON 字段再本地解析，有时比数据库内解析更快；但在 8.0 上，只要索引建对了，数据库内解析更稳、更可控
真正容易被忽略的是：8.0 的函数索引必须和查询表达式严格一致，连空格、括号风格都不能错；而 5.7 的生成列一旦写错或没设成 STORED，看起来建成功了，实际就是个摆设。
