背景

MySQL 协议中，当单条服务端→客户端消息（如一行含 >16MB 大字段的结果集）超过 0xFFFFFF（16MB-1）时，服务端应把消息拆成多个 payload 分包发送，并在每个包头上按 3 字节长度 + 递增的 sequence id 标识；消息长度恰为 0xFFFFFF 整数倍时还需补一个空包收尾。客户端再按同样规则重组。

dolphin 的入站方向已支持该重组（上游 fcd035ced fix: support MySQL multi-payload message reassembly，见 Plugin MR !2538），但出站方向未实现对称分块，导致 >16MB 的大结果（单 BLOB/BYTEA 字段或超长单行）读回失败。

现象

实习 #44（mysql crate 兼容性矩阵）实测（P7 用例）：

• 写入方向 OK：17MB BLOB 经 prepared statement / SEND_LONG_DATA 精确落库，LENGTH 正确 = 17825915（入站多包重组已生效）；
• 读回方向 FAIL：SELECT data 取回该 17MB 字段，客户端只收到少量字节（首 512B 即截断/错乱）。100KB 内完整逐字节回读正常，仅在单消息 >16MB 时触发。

根因

contrib/dolphin/plugin_protocol/bytestream.cpp 的出站函数 dq_putmessage()：

uint32 num = len;                 // 包头长度字段只有 3 字节（低 24 位）
for (; i < BYTE_3_LEN; i++) { header[i] = num & 0xff; ... }
header[i] = u_sess->proc_cxt.nextSeqid++;
internal_putbytes(packet, len);   // 正文一次性整包发送

对 len > 0xFFFFFF 的消息：包头只编码低 24 位、正文整段直接跟上，没有按 0xFFFFFF 分包、seq id 也不逐包递增，字节流直接错位，客户端重组失败 → 表现为结果截断/乱流。

修复思路（供参考，与入站 fcd035ced 对称）

在 dq_putmessage() 中循环发送：

1. len > 0xFFFFFF 时拆成若干块，每块 payload 长 0xFFFFFF（最后一块为剩余真实长度），每个包头写各自 payload 长度、seq id 逐包递增；
2. 若消息总长为 0xFFFFFF 的整数倍，末尾补一个 payload 长度 0 的空包收尾（与客户端预期一致）。

备注

• 该用例（>16MB 单字段回读）在实习 #44 中现仅断言写入 LENGTH（P7），未断言回读；修复后可补充逐字节回读断言。
• 关联实习 Issue：#44 https://gitcode.com/opengauss/opensource-intership/issues/44