MySQL 8.0 中 JSON_EXTRACT 查询更快，主要原因是解析器重写带来了优化，实测通常可提升 15%–35%。不过，这种性能提升必须建立在 strict_mode=ON、JSON 列为 NOT NULL、查询路径不含通配符等前提下；如果没有建立索引，不同版本之间的查询差异实际上几乎难以感知，真正决定性能的往往是函数索引设计以及 collation 排序规则的一致性。
MySQL 8.0 的 JSON_EXTRACT 确实比 5.7 更高效，但这种“更快”只会在特定场景下体现——很多开发者没有配好相关参数，也没有为 JSON 查询建立合适索引，实际执行时与 MySQL 5.7 的差别并不明显。
JSON_EXTRACT 在 8.0 里为什么变快了
根本原因在于解析器被重写：MySQL 8.0 采用原生 JSON parser，替换了 MySQL 5.7 中依赖的 Boost.PropertyTree，从而减少了内存拷贝、中间对象创建以及解析过程中的额外开销。实际测试中，单次 JSON_EXTRACT 函数调用平均可快 15%–35%，但需要注意，这一提升主要体现在函数本身的调用成本上。
- 前提一：
innodb_strict_mode=ON（MySQL 8.0 默认开启，5.7 默认关闭）——把数据校验前置，减少运行时因解析失败导致的重复回退 - 前提二：JSON 字段定义为
NOT NULL——在 MySQL 5.7 中，NULL 值会引入额外的空值检查，而 8.0 对这一路径做了优化 - 前提三：路径表达式不包含通配符（例如
$[*].id）——5.7 对数组展开支持有限，往往需要完整解析整个 JSON；8.0 在支持的同时加入了短路匹配优化，此时性能差距甚至可达到 3×
不建索引时，版本差异几乎不可测
即使 JSON_EXTRACT 本身快了 30%，只要查询条件仍然写成 WHERE JSON_EXTRACT(data, '$.status') = 'active'，并且 data 列没有任何索引，MySQL 依然需要逐行解析 JSON 并执行字符串比较。在这种情况下，性能瓶颈主要来自 I/O、全表扫描和解析过程，而不是 JSON_EXTRACT 函数实现本身。
- MySQL 5.7 通常只能依赖
STORED生成列再配合索引，这意味着写入时需要额外计算和存储，会增加空间占用和写入成本 - MySQL 8.0 支持函数索引：
CREATE INDEX idx_status ON t ( (JSON_EXTRACT(data, '$.status')) )，不需要冗余字段，索引可以直接建立在 JSON 表达式上 - 需要注意：函数索引要求表达式具备确定性，
JSON_EXTRACT()满足要求，但像NOW()、RAND()这样的非确定性函数则无法用于建立索引
字符集与排序规则会影响结果一致性
JSON_EXTRACT 返回的是 JSON 类型值，在比较时通常会发生隐式字符串转换。而 MySQL 5.7 常见的默认排序规则是 utf8mb4_general_ci（大小写不敏感），MySQL 8.0 默认则更常见为 utf8mb4_0900_as_cs（大小写敏感）。
- 例如语句
JSON_EXTRACT(data, '$.Name') = '"admin"'在 MySQL 5.7 中可能匹配到{"name": "admin"}，但在 MySQL 8.0 的默认设置下通常不会命中 - 这并不是 bug，而是 collation 排序规则差异带来的正常结果；如果误以为是“8.0 查询结果不准确”，就很容易让性能测试结论产生偏差
- 更稳妥的做法是显式指定
COLLATE utf8mb4_bin统一比较行为，例如：JSON_EXTRACT(data, '$.Name') COLLATE utf8mb4_bin = '"admin"'
真正卡慢的从来不是函数，而是你没把 JSON 当字段对待
很多人在优化 MySQL JSON 查询时，只盯着 JSON_EXTRACT 那一点毫秒级性能差异，却忽视了真正关键的问题：只要 JSON 字段出现在 WHERE、ORDER BY 或 JOIN 条件中，就必须把索引策略、表达式设计和查询路径一并纳入优化范围。MySQL 8.0 提供的函数索引、部分更新以及 JSON_TABLE 等能力，本质上都是为了让 JSON 从“附属文档”升级为“可查询、可分析的结构化字段”。如果没有合理利用这些能力，仅仅从 MySQL 5.7 升级到 8.0，往往并不能真正解决 JSON 查询慢的问题，最多只是把原本发生在应用层的性能负担转移到了数据库层。
