笙亿网络策划

MariaDB 处理 JSON 数据类型性能不如 MySQL 5.7 吗？

约 6 分钟读完 2 阅
文章导读
MariaDB 与 MySQL 5.7 在 JSON 处理上的性能差异主要源于存储引擎实现不同，不能简单判定谁更优。MySQL 5.7 使用原生二进制格式存储 JSON，支持有效性检查但存在运行时解析开销；MariaDB 将 JSON 视为 LONGTEXT 别名，依赖函数处理，公开资料中缺乏直接的性能基准测试数据支持某一方绝对领先。
📋 目录
  1. A 命令速用版
  2. B 为什么会这样
  3. C 分步处理
  4. D 怎么验证是否生效
  5. E 常见坑
  6. F 常见问题
  7. G 参考来源
A A

MariaDB 与 MySQL 5.7 在 JSON 处理上的性能差异主要源于存储引擎实现不同，不能简单判定谁更优。MySQL 5.7 使用原生二进制格式存储 JSON，支持有效性检查但存在运行时解析开销；MariaDB 将 JSON 视为 LONGTEXT 别名，依赖函数处理，公开资料中缺乏直接的性能基准测试数据支持某一方绝对领先。

先说结论：架构实现不同导致适用场景差异，而非单纯的性能高低，需根据业务对校验和索引的需求选型。

  • 适合：需要原生 JSON 校验和二进制存储选 MySQL 5.7，需要兼容性与文本处理灵活性选 MariaDB。
  • 重点看：MySQL 5.7 大文档解析耗时较高，MariaDB 无原生类型约束但声称无显著性能差异。
  • 别忽略：MariaDB 官方未提供基准测试数据支持其性能说法，MySQL 5.7 虚拟列索引需表达式完全一致才生效。

命令速用版

通过以下命令快速确认当前数据库的 JSON 实现机制和版本，避免误判性能瓶颈。

-- 查看数据库版本
SELECT VERSION();

-- 查看表结构确认 JSON 列实际类型
SHOW CREATE TABLE your_table_name;

-- 检查查询是否走索引（MySQL 5.7 虚拟列）
EXPLAIN SELECT * FROM your_table WHERE json_col->>'$.key' = 'value';

为什么会这样

性能差异的根本原因在于 MySQL 5.7 采用原生二进制存储而 MariaDB 采用文本别名存储。MySQL 5.7 从 5.7.7 labs 版本开始 InnoDB 存储引擎原生支持 JSON 格式，数据有效性检查和查询不需要遍历所有字符串，但 JSON_EXTRACT 等函数每次调用都触发完整解析，大 JSON 文档会显著拖慢查询吞吐。MariaDB 没有提供原生 JSON 数据类型增强功能，认为 JSON 数据类型不是 SQL 标准的一部分，为 JSON 定义了一个别名，实际上就是一个 LONGTEXT 列，虽然声称两者之间没有显著的性能差异，但并没有提供基准测试数据来支持这个说法。

分步处理

根据业务需求选择数据库或优化现有 JSON 查询，避免盲目迁移导致性能下降。

步骤 1：确认存储机制
检查现有表结构，MySQL 5.7 显示为 JSON 类型，MariaDB 显示为 LONGTEXT。若业务强依赖 JSON 格式校验，MySQL 5.7 能在数据库层做约束性检查，BLOB 类型无法做到。

步骤 2：评估查询模式
若频繁查询 JSON 内部字段，MySQL 5.7 可通过虚拟列功能对 JSON 中的部分数据进行索引，但需注意虚拟列不自动加速原生 JSON 表达式，优化器不会自动重写语句除非表达式字面完全一致且类型匹配。

步骤 3：大文档优化
对于超过 20KB 的 JSON 文档，MySQL 5.7 单次解析耗时可能达 0.8–3ms，10 万行扫描就是秒级延迟，建议将高频查询字段提取为独立列，避免全量解析。

怎么验证是否生效

通过执行计划和分析函数耗时确认优化效果，确保索引被正确利用。

检查索引命中：使用 EXPLAIN 查看查询计划，若 type 显示为 ALL 且 rows_examined 等于表总行数，说明未走索引，需检查虚拟列定义是否与查询表达式完全一致。

MariaDB 处理 JSON 数据类型性能不如 MySQL 5.7 吗？

检查类型匹配：若 JSON 里存的是数字，必须用 CAST 定义生成列，否则比较会走字符串字典序导致索引失效，常见翻车是用了 JSON_EXTRACT 却建了 VARCHAR 虚拟列。

常见坑

在 JSON 索引和迁移过程中容易遇到的陷阱，需提前规避。

索引失效风险：B+ 树索引根本看不见 JSON 内部字段，JSON 列本身在磁盘上是紧凑的二进制 blob，无法感知路径是否存在，没有函数索引的 MySQL 5.7 版本需手动创建虚拟列。

表达式一致性：真正卡住性能的往往不是 JSON 解析本身，而是误以为加了虚拟列就万事大吉，却忽略了表达式一致性、类型映射和优化器重写边界，这些细节在 5.7 中比 8.x 更敏感。

迁移兼容性：MariaDB 支持的 JSON 特性并没有 MySQL 的多，尤其是在处理 JSON 的嵌套时，使用的方法比较复杂，开发者在跨数据库迁移时常因一条看似无害的 sql 报错而陷入排查困境。

常见问题

MariaDB 的 JSON 类型和 MySQL 一样吗？

不一样，MariaDB 将 JSON 定义为 LONGTEXT 列别名，而 MySQL 5.7 支持原生 JSON 数据类型。

MySQL 5.7 JSON 查询为什么慢？

因为 MySQL 5.7 的 JSON 解析是全行、逐行、运行时完成的，不支持预编译或路径索引，大 JSON 文档会显著拖慢查询吞吐。

MariaDB 能建立 JSON 索引吗？

MariaDB 早期版本基于 Dynamic Columns 思路实现，底层是 BLOB 类型存储，不能有效建立索引，查询性能不高。

参考来源

  • 为什么 MySQL 5.7 的 JSON 函数性能在处理大文件时较差？
  • MariaDB 和 MySQL 全面对比：选择数据库需要考虑这几点
  • MySQL 5.7 原生 JSON 格式支持 - 海东潮 - 博客园
  • mysql 和 mariadb 区别
  • 关于 MariaDB 和 mysql5.7 的 json 类型特性