如何序列化MYSQL_RES？寻求替代JSON的跨服务器传输优化方案

哥们，你的场景我太熟悉了——JSON在高频大量数据传输+密集小查询的场景下确实会成为性能瓶颈，毕竟文本格式的序列化/反序列化绕不开字符串转换和内存拷贝的开销，尤其是你说的“服务器启动+每分钟批量数据+数千次小查询”的组合，JSON的解析延迟会被无限放大。我来帮你拆解下Protobuf和Flatbuffer的适配性，以及具体怎么处理MYSQL_RES的序列化。

一、先搞懂两个序列化方案的核心差异 #

Protobuf（Protocol Buffers） #

这是Google出的老牌二进制序列化方案，特点是体积小、解析快、生态成熟：

• 优点：
  • 序列化/反序列化速度比JSON快3-5倍，数据压缩率能达到JSON的1/3甚至更低；
  • 几乎所有主流语言都有成熟的支持库，开发成本低；
  • 提前定义Schema（.proto文件），数据结构清晰，变更可控。
• 缺点：
  • 解析时需要把整个数据块加载到内存中（虽然比JSON省很多），超大规模数据集可能会有内存压力；
  • 需要维护Schema文件，结构变更要同步更新所有服务端和客户端。

Flatbuffers #

这是Facebook出的更极致的二进制方案，核心卖点是零拷贝解析：

• 优点：
  • 不需要把整个序列化后的字节流加载到内存，直接从原始字节中读取指定字段，完全避免中间内存分配和拷贝，解析速度理论上比Protobuf更快；
  • 同样支持Schema，且向后兼容性好，适合内存敏感或者超大数据集的场景。
• 缺点：
  • 序列化时的开销比Protobuf略高（因为要构建字段索引结构）；
  • API使用起来更繁琐，尤其是处理复杂嵌套结构时，代码量会比Protobuf多一些。

二、针对MYSQL_RES的序列化实现思路 #

不管选哪种方案，核心都是跳过JSON的文本转换环节，直接把MYSQL_RES里的元数据（字段名、类型、数量）和行数据映射到二进制结构里。

方案1：用Protobuf处理MYSQL_RES #

1. 定义.proto Schema：先对应你用到的MySQL字段类型，定义通用的结果集结构：

syntax = "proto3";

package db_result;

// 枚举对应MySQL的字段类型
enum FieldType {
    INT = 0;
    VARCHAR = 1;
    FLOAT = 2;
    DATE = 3;
    // 按需添加你用到的其他类型，比如DECIMAL、BLOB等
}

// 单个字段的元数据
message FieldMeta {
    string name = 1;
    FieldType type = 2;
}

// 单行数据，按类型分类存储（避免用Any类型增加开销）
message RowData {
    repeated int64 int_values = 1;
    repeated string varchar_values = 2;
    repeated float float_values = 3;
    repeated string date_values = 4;
}

// 完整的查询结果集
message ResultSet {
    repeated FieldMeta fields = 1;
    repeated RowData rows = 2;
}

2. 序列化端（数据库连接服务器）：
   • 调用mysql_fetch_fields()获取MYSQL_RES的字段列表，逐个填充FieldMeta；
   • 遍历每一行mysql_fetch_row()，根据字段类型把数据转成对应Protobuf字段的类型（比如INT直接转成int64，VARCHAR直接存原始字符串）；
   • 调用Protobuf的SerializeToString()或SerializeToArray()把ResultSet转成字节流，直接发给客户端连接服务器。
3. 反序列化端（客户端连接服务器）：
   • 接收字节流后，直接反序列化成ResultSet对象；
   • 根据FieldMeta的类型，从RowData中取出对应的数据，直接转换成业务需要的数据集——完全不需要像JSON那样做字符串解析，省了大量CPU开销。

方案2：用Flatbuffers处理MYSQL_RES #

1. 定义.fbs Schema：类似Protobuf，定义结果集结构：

namespace db_result;

enum FieldType : byte { INT, VARCHAR, FLOAT, DATE }

struct FieldMeta {
    name: string;
    type: FieldType;
}

table RowData {
    int_values: [int64];
    varchar_values: [string];
    float_values: [float];
    date_values: [string];
}

table ResultSet {
    fields: [FieldMeta];
    rows: [RowData];
}

root_type ResultSet;

2. 序列化端：
   • 用Flatbuffers的Builder对象逐步构建ResultSet：先添加所有FieldMeta，再逐行添加RowData；
   • 构建完成后调用Finish()生成字节流，直接发送即可——Flatbuffers不需要中间对象，内存效率很高。
3. 反序列化端：
   • 接收字节流后，直接调用GetRoot<ResultSet>()获取根对象，不需要整个反序列化；
   • 读取字段时直接从原始字节中取，比如result->fields()->Get(i)->name()，完全零拷贝——这对密集小查询场景特别友好，因为小查询的结果集小，零拷贝能把响应延迟降到最低。

三、选型建议 #

• 如果你的场景中批量数据传输占主导，同时希望兼顾开发效率和生态支持，选Protobuf：它的序列化速度足够快，代码生成工具完善，维护成本低，团队上手也快。
• 如果你的场景中小查询非常密集，或者客户端连接服务器内存资源紧张，选Flatbuffers：零拷贝解析能极大减少内存分配和拷贝的开销，小查询的响应速度会有明显提升——虽然序列化时开销略高，但小查询的数据量小，整体收益更高。

另外，给你加个小优化技巧：对于高频的小查询，可以在数据库连接服务器端做序列化结果缓存，把已经序列化好的字节流缓存起来，避免重复从MySQL查询和序列化，进一步降低延迟。

内容的提问来源于stack exchange，提问作者Prasanth Madhavan