net_buffer_length仅控制连接初始化时的缓冲区起点，默认16KB，不影响查询结果截断；真正决定GROUP_CONCAT长度的是group_concat_max_len，限制单包大小的是max_allowed_packet。
net_buffer_length 不控制查询结果是否被截断
它只决定每个客户端连接刚建立时，服务端分配的初始网络缓冲区大小，默认 16KB（16384），不是“结果缓存上限”。你看到 GROUP_CONCAT() 截断、长文本字段变短、或 ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes，和 net_buffer_length 没关系。
真正起作用的是：
-
group_concat_max_len：控制GROUP_CONCAT()返回字符串最大长度，默认1024 -
max_allowed_packet：约束单个数据包最大尺寸，服务端和客户端都必须设够 - 客户端驱动行为：比如 PyMySQL 默认启用
use_unicode=True，UTF-8 编码可能让实际字节数翻倍，间接触发max_allowed_packet限制
net_buffer_length 在什么环节起作用？
它仅参与连接初始化阶段的内存预分配，影响极早期握手、小 SQL 提交、以及第一个结果集拉取前的缓冲区起点。MySQL 内部有两个缓冲区：connection buffer 和 result buffer，它们初始大小都由 net_buffer_length 设定，但运行中会自动扩容——上限就是 max_allowed_packet。
关键事实：
- 修改
net_buffer_length必须重启mysqld，不能用SET SESSION或SET GLOBAL - 设得太小（如
4096）会导致频繁 realloc，但对普通查询几乎无感；设得过大（如32M）纯属浪费，因为只是“起点”，不改变上限 - 每次 SQL 执行完，
result buffer会缩回net_buffer_length大小，为下一次做准备
mysqldump 中的 --net-buffer-length 是另一回事
这个参数属于 mysqldump 客户端工具，和服务器端的 net_buffer_length 系统变量无关。它控制的是 mysqldump 自己内部拼接 INSERT 语句时的缓冲区大小，影响单条 INSERT ... VALUES (...), (...), ... 的行数。
例如：
-
mysqldump --net-buffer-length=1048576会让导出文件里每条 INSERT 包含最多约 1MB 的值列表，提升导入速度 - 但它不影响服务端接收能力——导入时仍需确保服务端
max_allowed_packet≥ 这个值，否则报错 - 该参数在命令行中使用，不写入 MySQL 配置文件，也不影响其他客户端（如 mysql 命令行、应用程序）
遇到结果截断，优先检查这三处
别急着调 net_buffer_length。先确认以下三点是否匹配你的场景：
- 查
SELECT @@group_concat_max_len，若用GROUP_CONCAT()，就 SET SESSIONgroup_concat_max_len = 1000000 - 查
SELECT @@max_allowed_packet（服务端）和客户端连接参数（如 PyMySQL 的connect(..., max_allowed_packet=...)），两边都要 ≥ 实际最大单包尺寸 - 抓包验证：用
tcpdump或 Wireshark 看返回是否真被拆成大量小包；如果是，且应用层没做流式读取（如 C API 漏掉mysql_store_result()），那问题在客户端消费逻辑，不在缓冲区
真正容易被忽略的是：客户端和服务端的 max_allowed_packet 不一致，或者应用代码没正确消费完整结果集——这时候调任何缓冲区参数都没用。
