MySQL 8.0.23中JSON_ARRAYAGG单查询与双查询性能对比

在MySQL 8.0.23环境下，存在两种查询场景：

场景1：两次独立查询 #

select *
from boards b
where b.id = 11

select *
from comments c 
where c.board_id = 11

场景2：单查询关联并生成JSON #

select b.*
     , c.comments
from boards b 
left outer join lateral (
  select json_arrayagg(json_object(
    'id', c.id,
    'title', c.title,
    ...
  )) as comments
  from comments c 
  where c.board_id = b.id
) c on true
where b.id = 11

问题：哪种查询方式性能更优？不关注反模式相关内容，核心疑问是减少连接成本一次性获取数据，还是避免JSON转换成本更好？测试中场景2的查询响应速度更快，但想知道哪种方式能让MySQL服务器在相同时间内处理更多查询。

要判断哪种方式能提升服务器查询吞吐量（相同时间处理更多查询），可以从三个核心维度分析：

1. CPU开销对比 #

• 场景1：两次查询都是基于索引的单表查找（假设boards.id、comments.board_id已建索引），没有额外计算逻辑，CPU仅消耗在查询解析、索引扫描和结果集组装上，开销极低。
• 场景2：虽为单次查询，但需执行json_object逐条将评论行转为JSON对象，再通过json_arrayagg聚合为JSON数组。这两个函数属于CPU密集型操作，当目标评论数量较多时，JSON序列化的CPU开销会显著上升，直接占用服务器CPU资源，导致并发处理能力下降。

2. 连接与会话资源对比 #

• 场景1：若应用使用连接池，两次请求的连接复用开销可忽略；即使无连接池，短查询的连接建立/销毁开销也远低于JSON序列化的CPU消耗。
• 场景2：单次请求减少了一次网络往返，但这种优势在高并发场景下，远抵不上JSON序列化消耗的CPU资源对吞吐量的负面影响。

3. 数据传输量对比 #

• 场景1：返回原生行数据，字段为MySQL原生类型，数据体积紧凑。
• 场景2：返回JSON格式聚合数据，文本格式的体积远大于原生数据，会增加网络传输时间和服务器IO开销，间接降低吞吐量。

结论 #

如果核心目标是提升服务器整体查询吞吐量，场景1的表现更优——虽然多了一次请求，但避免了高CPU开销的JSON序列化操作，能让服务器CPU资源服务于更多查询请求。

你测试中场景2响应更快，大概率是因为单次请求减少了网络往返时间（比如应用与数据库跨机房部署时网络延迟占比高），但这种优势仅体现在单请求响应速度上，而非服务器的整体吞吐量。

内容的提问来源于stack exchange，提问作者dne he