本文是 MySQL 简单查询语句执行过程分析 6 篇中的第 6 篇，第 1 ~ 5 篇请看这里：
1. 词法分析 & 语法分析
2. 查询准备阶段
3. 从 InnoDB 读数据
4. WHERE 条件
5. 发送数据给客户端
网络缓冲区，顾名思义，就是从网络连接读取数据，或者向网络连接发送数据时使用的缓冲区。
说到 MySQL 的网络缓冲区，不得不先说一个 MySQL 系统变量 net_buffer_length，从它的名字可以看到，这个系统变量是用来控制网络缓冲区大小的。
由于对 net_buffer_length 这个系统变量的印象根深蒂固，我一直认为 MySQL 只有一个网络缓冲区，直到最近研究源码的时候又看了一下官方文档中关于 net_buffer_length 的描述，才发现在内部实现中，实际上用了 2 个缓冲区。
官方文档描述的意思是这样的：
每个客户端线程都关联了 1 个连接缓冲区（connection buffer）和 1 个结果集缓冲区（result buffer），这 2 个缓冲区的初始大小都由 net_buffer_length 控制，需要时最大可以自动增长到不超过 max_allowed_packet。每条 SQL 语句执行完成后，结果集缓冲区都会自动恢复到 net_buffer_length 指定的大小。
一般情况下，不应该修改 net_buffer_length 的值，如果这个值设置得非常小，你可以把它修改为客户端发送的 SQL 语句预期的长度。如果 SQL 语句长度超过这个值，连接缓冲区还会自动增长。net_buffer_length 的最大值为 1048576（1M）。
看到上面两段描述，可能有的小伙伴会奇怪，为什么第一段中说连接缓冲区的小大可以自动增长到不超过 max_allowed_packet，第二段中却说 net_buffer_length 最大只能设置为 1048576，这不是矛盾吗？这个逻辑是没问题的，net_buffer_length 只用来控制连接缓冲区的
初始大小，一旦连接缓冲区初始化完成，它就不受 net_buffer_length 控制了，而是受 max_allowed_packet 控制，也就是说：net_buffer_length 控制连接缓冲区的下限，max_allowed_packet 控制连接缓冲区的上限。
以下是官方文档原文：
Each client thread is associated with a connection buffer and result buffer. Both begin with a size given by net_buffer_length but are dynamically enlarged up to max_allowed_packet bytes as needed. The result buffer shrinks to net_buffer_length after each SQL statement. This variable should not normally be changed, but if you have very little memory, you can set it to the expected length of statements sent by clients. If statements exceed this length, the connection buffer is automatically enlarged. The maximum value to which net_buffer_length can be set is 1MB.
从官方的描述可以看到几个关键点：
- 缓冲区有 2 个：连接缓冲区、结果集缓冲区。
- 缓冲区初始大小都由 net_buffer_length 控制。
- net_buffer_length 的大小不能超过 1M。
- 连接缓冲区可以自动增长，但是其大小必须
小于等于max_allowed_packet。
数据包是 MySQL 发送数据的基本单元，接下来我们从数据包开始，分为三个部分来聊聊网络缓冲区那些事。
1. 数据包（packet）
MySQL 中，客户端发送数据给服务端、服务端发送执行结果给客户端，都是以数据包（packet）为单元发送的。
每个数据包，都由包头、包体两部分组成，包头由 3 字节的包体长度、1 字节的包编号组成。3 字节最多能够表示 2 ^ 24 = 16777216 字节（16 M），也就是说，一个数据包的包体长度必须小于等于 16M。
如果要发送超过 16M 的数据怎么办？
分而治之在解决各种问题的时候经常会用到，MySQL 就是用这种思路解决数据包超过 16M 的问题的。
当要发送大于 16M 的数据时，会把数据拆分成多个 16M 的数据包，除最后一个数据包之外，其它数据包大小都为 16M。
2. 连接缓冲区
连接缓冲区，有 2 个应用场景：
- 从客户端接收数据，把数据暂存到连接缓冲区。
- 发送执行结果给客户端，
可能会先把执行结果暂存到连接缓冲区，待缓冲区满再一次性发送。
后面会解释为什么是
可能，而不是一定把执行结果暂存到连接缓冲区。
虽然接收、发送两个场景都使用了连接缓冲区，并且是共用同一个连接缓冲区，但它们之间还是有一些区别，请继续往下看。
2.1 从客户端接收数据
每次服务端接收客户端发来的数据，写入数据到连接缓冲区之前，都会判断连接缓冲区中的剩余空间，是否足够写入新数据。
如果剩余空间不够写入新数据，会重新分配更大的内存空间，这就是前面提到的连接缓冲区可以自动增长。
重新分配的内存空间大小是写入新数据之后的数据总长度，并且以 4096 字节对齐（也就是 4096 的整数倍）。
举个例子：假设写入新数据之前，连接缓冲区的大小为 4096 字节，缓冲区中已经有 1688 字节数据，而即将要写入的新数据为 5000 字节，写入新数据后数据总长度为 1688（已有数据） 5000（新数据） = 6688 字节，连接缓冲区空间不够，需要分配更大的空间，因为要按 4096 字节对齐，所以新分配的空间大小为 8192 字节。
一般情况下，客户端发送数据给 MySQL 服务端，服务端把数据暂存到连接缓冲区，就可以进行后续的操作了。
就这么简单吗？是的，一般情况下，连接缓冲区的使用就是这么简单，但凡事都可能有例外，连接缓冲区也不能免俗，当客户端发送的数据长度比较小的时候，这就是个简单的你发我收的过程（顶多是空间不够了，就加大点），而当客户端发送的数据很长的时候（如 insert 批量插入、update ... case ... when 批量更新），这个过程就会复杂一些了。
SQL 语句很长的时候，不也就是发和收吗，为什么就会更复杂？
这就像我们写代码的时候一样，如果不考虑高并发，写起来很简单，一旦要考虑高并发，就需要缓存、分布式、微服务等各路神仙通通上马了。
服务端读取客户端发来的数据包的包头信息时，如果发现包体长度等于 16M，它就知道本次接收的数据由多个数据包组成，会先把当前数据包的内容写入连接缓冲区，然后接着读取下一个数据包，并把下一个数据包的内容追加到连接缓冲区，直到读到结束数据包，就接收到客户端发送的完整数据了。
2.2 发送执行结果给客户端
服务端发送执行结果给客户端时，会有 2 种方式：
- 如果执行结果数据
大于连接缓冲区大小，数据不会写入连接缓冲区，而是直接发送给客户端。 这里的连接缓冲区，就是服务端接收客户端发来的数据时使用的那个连接缓冲区。 - 如果执行结果数据
小于等于连接缓冲区大小，会先写入连接缓冲区，等连接缓冲区满之后发送给客户端。
实际上源码中，处理的逻辑要更复杂一些，我这里舍弃了小部分细枝末节，不然就变成了描述代码流程，那看起来就很费劲了。
为什么执行结果数据大于连接缓冲区大小时就不使用连接缓冲区了？
这就要说到连接缓冲区的作用了，连接缓冲区本来就是为了把多个小的数据包（packet）攒起来一起发送，如果执行结果数据超过了连接缓冲区的大小，那就不需要攒着一起发了，服务端直接把数据包发送给客户端，还能节省拷贝数据到连接缓冲区的时间。
这就解释了前面所说的，执行结果数据是可能，而不是一定会暂存到连接缓冲区。
还有一点需要说明的是，如果执行结果数据超过 16M，也一样会分为多个数据包发送，客户端接收数据时，会把多个数据包合并起来，得到完整的执行结果数据。
3. 结果集冲区
为什么有了连接缓冲区之后，还要再弄个结果集缓冲区呢？
server 层从存储引擎读取到一条符合 where 条件的记录之后，一条记录需要作为一个整体发送给客户端，这就需要个临时空间把各字段内容攒到一起，这个临时空间就是结果集缓冲区。
结果集缓冲区的初始值，也是由 net_buffer_length 控制的，默认为 16K，当结果集缓冲区剩余空间不够容纳新的数据时，会重新分配更大的内存空间，重新分配空间时，是按 8 字节对齐的，例如：如果需要 7509 字节来存储数据，会分配 7512 字节的空间。
字段内容写入结果集缓冲区的过程是这样的：遍历要发送给客户端的字段列表，读取字段内容到结果集缓冲区，如果缓冲区剩余空间不够存储即将要写入的字段内容，重新分配更大的内存空间，然后把字段内容追加到缓冲区，并更缓冲区内容总长度。
当一条记录中所有字段的内容都已经写入结果集缓冲区之后，组装也就完成了，然后把结果集缓冲区中的数据写入连接缓冲区或者直接发送给客户端。
4. net_buffer_length
net_buffer_length 初始值为 16384 字节（16K），最小可设置为 1024 字节（1K）最大可设置为 1048576 字节（1M），并且必须小于等于 max_allowed_packet。
官方文档中描述 net_buffer_length 时，有个不起眼的小东西：Block Size，它的值为 1024，表示 net_buffer_length 必须是 1024 的整数倍，并且是向下取整数倍的，它的计算逻辑为：(net_buffer_length / 1024) * 1024。
举例说明：假设 my.cnf 中配置 net_buffer_length = 2047，那么计算逻辑为：(2047 / 1024) * 1024 = 1024，因为在 c 语言中，两个整数相除得到的结果也是整数，并且是直接舍弃小数，而不是四舍五入，所以，2047 / 1024 = 1。
5. max_allowed_packet
max_allowed_packet 初始值为 4194304 字节（4M），最小值为 1024 字节（1K），最大值为 1073741824（1G）。
max_allowed_packet 既会限制客户端发送给服务端的数据大小，也会限制服务端发送给客户端的数据大小，max_allowed_packet 最大值只能设置为 1G，因此，客户端和服务端之间，不管谁给谁发送数据，一次发送的数据最多只能有 1G，这是个硬限制。
官方文档中描述 max_allowed_packet 时，也有一个 Block size，它的值也是 1024，和 net_buffer_length 的计算逻辑是一样的。
6. 总结
本文主要介绍了 MySQL net_buffer_length 背后的两个缓冲区：连接缓冲区、结果集缓冲区，并介绍了这两个缓冲区的自动增长逻辑，以及它们的上下限。还介绍了 MySQL 客户端和服务端数据交互的基本单元是数据包（packet），以及超过 16M 的大数据怎么发送和接收。最后介绍了 net_buffer_length、max_allowed_packet 两个系统变量的配置，以及一个不起眼的小东西 Block Size。
