net_buffer_length仅控制客户端连接初始网络缓冲区大小，非结果缓存限制；真正决定查询结果能否完整返回的是max_allowed_packet，且group_concat()等函数受group_concat_max_len独立约束。
MySQL 没有所谓“查询结果缓存限制”这个配置项，net_buffer_length 也不是用来控制结果缓存大小的——它只影响服务器与客户端之间单次网络包的初始缓冲区大小，且对查询结果能否返回、是否截断完全不生效。
为什么 net_buffer_length 常被误认为是“结果缓存限制”
常见错误现象是：执行 SELECT GROUP_CONCAT(...) 或长文本字段时，结果被意外截断，日志里又看到 net_buffer_length 相关描述，于是误判为“缓存不够”。实际根本原因通常是：
-
GROUP_CONCAT()受group_concat_max_len限制（默认 1024），不是net_buffer_length - 大结果集被截断，真正瓶颈在
max_allowed_packet（服务端+客户端双向限制） -
net_buffer_length仅用于初始化连接时的内部读写缓冲，MySQL 会按需自动扩容，只要不超过max_allowed_packet就不会出问题
net_buffer_length 的真实作用和取值逻辑
这个参数定义的是 MySQL 服务端为每个客户端连接分配的**初始网络缓冲区大小**，仅在连接建立初期使用。它的行为特点是：
- 默认值通常为 1MB（1048576 字节），但实际运行中会被动态拉伸，上限由
max_allowed_packet决定 - 无法通过
SET SESSION或SET GLOBAL动态修改，必须在配置文件中设置并重启 mysqld 才生效 - 设得过小（如 16K）可能导致极早期的握手或小查询多一次内存重分配，但几乎不影响业务查询
- 设得过大（如 32M）毫无意义——它只是“起点”，真正承载大数据量的是
max_allowed_packet
真正控制“查询结果能否完整返回”的参数是 max_allowed_packet
如果你遇到结果截断、ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes 等错误，要调的是这个：
- 它同时约束服务端接收和发送的最大单个数据包长度
- 需在服务端（
[mysqld]）和客户端（[mysql]或连接字符串）两端都设够，否则任一端卡住都会失败 - 示例配置（推荐从 64M 起步）：
[mysqld]<br>max_allowed_packet = 64M<br><br>[mysql]<br>max_allowed_packet = 64M
- 动态生效（仅对新连接）：
SET GLOBAL max_allowed_packet = 67108864;，但重启后失效，务必同步改配置文件
容易被忽略的关键点
很多团队花时间调 net_buffer_length 却解决不了截断问题，是因为混淆了协议层缓冲和语义层限制。更隐蔽的坑在于：
- 应用使用的驱动（如 MySQL Connector/J）可能自带默认
maxAllowedPacket，比服务端还小，必须显式覆盖 -
GROUP_CONCAT()、JSON_ARRAYAGG()等聚合函数有自己独立的长度限制，必须单独调group_concat_max_len或cte_max_recursion_depth等 - 即使所有参数都调大，如果客户端内存不足或网络中间件（如 HAProxy、ProxySQL）限制了包大小，依然会截断
