MySQL中如何压缩存JSON的mediumtext字段降低高频查询耗时

你已经排除索引问题，结合count(*)执行极快的现象，查询耗时1秒完全是mediumtext大JSON字段带来的IO、内存放大问题：

• 单行平均大小9704字节，InnoDB默认数据页大小为16KB，单页最多存1~2行完整数据，对比常规小字段表单页可存几十至上百行，同等查询量下需要读取的物理页数量翻几十倍，随机IO开销陡增
• count(*)仅需遍历二级索引即可返回结果，不需要回表读取完整行数据，所以速度极快，和你观测到的现象完全匹配
• 高并发场景下，大字段会快速挤占InnoDB Buffer Pool空间，热点数据页命中率持续下降，进一步放大查询延迟
• 如果查询时不需要读取JSON字段却每次都拉取全表字段，大字段所在的数据页仍会被加载到内存，平白浪费内存和IO带宽

1. 首选方案：垂直拆表 #

这是收益最高、长期最稳定的方案，改造成本可控：

• 将原表拆为两张关联表：主表仅存储除mediumtextJSON字段外的所有高频访问小字段，扩展表存储「主键ID + 原JSON大字段」，两表通过主键ID关联
• 拆完后主表单行大小通常能降到百字节以内，单个16KB数据页可存上百行，回表查询的IO开销直接下降两个数量级，不涉及JSON字段的常规查询耗时会直接降到毫秒级
• 仅当业务明确需要读取完整JSON内容时，才关联查询扩展表取大字段。这类查询占比通常远低于普通字段查询，改造后整表的QPS承载能力可提升10倍以上
• 对一致性要求不高的场景，insert操作可先写主表返回成功，再异步写入扩展表，进一步降低写入延迟

2. 过渡方案：存储配置优化 #

如果暂时无法推进拆表改造，可先做以下调整快速降低延迟：

• 杜绝select *写法：梳理所有查询语句，不需要JSON字段的场景明确指定查询列，不要拉取全量大字段；如果仅需JSON内的部分字段，直接用MySQL原生JSON函数按路径提取目标内容，不要返回完整JSON串
• 调整InnoDB行格式：确认表使用DYNAMIC或COMPRESSED行格式（对应innodb_file_format为Barracuda），长度超过768字节的大字段会自动存在独立的溢出页，主数据页仅存20字节的字段指针，可大幅缩小主数据页体积，提升单页可存储的行数
• 优化Buffer Pool配置：给数据库实例分配足够内存，将innodb_buffer_pool_size设置为实例物理内存的50%~70%，提升热点数据页命中率，减少磁盘随机IO

3. 长期方案：冷热数据分离 #

如果大JSON字段的访问频率极低（仅排障、审计场景读取）：

• 直接将大JSON内容迁移到对象存储，数据库表内仅存储对象存储的文件访问地址，彻底消除大字段对数据库性能的影响
• 按时间做冷热分层，近1~3个月的热点JSON存在数据库扩展表，超过时限的冷数据归档到对象存储，查询时按时间条件路由，进一步降低数据库的存储和访问压力

• 不要盲目给JSON字段加冗余索引：你已经确认索引无瓶颈，额外索引只会降低insert写入性能，加剧高并发下的锁冲突
• 不要盲目开启全表压缩：压缩会带来额外的CPU开销，高并发写入场景下反而可能导致延迟升高，优先选择拆表方案
• 不要单靠升级实例规格硬扛：垂直升配只能暂时缓解问题，大字段带来的IO放大逻辑不解决，QPS上涨后必然会出现延迟毛刺

内容的提问来源于stack exchange，提问作者Adi Israel