MySQL通讯协议（2）数据包
- 将数据分成大小为(2^24−1)字节的数据包
- 给每个数据块加上一个包头
由于连接的创建和释放都需要耗费资源，所以数据库这种交互频繁，且连接数量不需要特别大的应用场景，一般使用长连接。
使用短连接尚能通过RST判断数据是否读完了，而长连接就不能这么做了，同时由于TCP的特点，数据读写会发生拆包、粘包。所以使用长连接传输数据，必须通过某种方法把要发送的数据告诉接收方。例如HTTP协议head里的CONTENT-LENGTH。也可以通过特殊的符号判断，不过由于消息里可能也会出现这些符号，会发生歧义，所以应用场景受限。还有一种最简单的方法就是每次发送固定长度消息，不够用0填充。
MySQL数据包结构
Type Name Description
int<3>
payload_length
payload的长度，整数类型。不包括包头四个字节
int<1>
sequence_id
Sequence ID
string
payload
有效载荷，字符串类型。长度=payload_length
消息包分为两个部分，包头+包体。
包头固定四个字节，前三个字节是整数型的payload长度，第四个是整数型的消息序列号。
包体就是这个包的有效载荷，长度由前三字节指定，内容根据具体场景各不相同。
例如，一个消息为03 00 00 01 01 02 03 04。先读取前四个字节，发现这个消息包体有3个字节，这个消息序号是0，消息内容是01 02 03，后面的04是下一个包的数据。
包体长度
由于包体长度是由三个字节记录的，三个字节能表示的最大值为FF FF FF，即1<24-1=2^24-1=16777215=15.999...M。所以，一个MySQL消息包体不能超过16MB。如果超过16MB，就分多次发送。
消息序号
消息号用来标记每个消息的顺序，会自动增长，并循环。
通用响应包
对于大多数请求，服务端有一些通用的响应包结构。
OK_Packet
命令成功完成后的响消息。
Type Name Description
int<1>
header
[00] 或 [fe]
int<lenenc>
affected_rows
affected rows 影响行数
int<lenenc>
last_insert_id
last insert-id 最后插住数据id
if capabilities & CLIENT_PROTOCOL_41 {
int<2>
status_flags
Status Flags
int<2>
warnings
警告数量
} else if capabilities & CLIENT_TRANSACTIONS {
int<2>
status_flags
Status Flags
}
if capabilities & CLIENT_SESSION_TRACK {
string<lenenc>
info
容易理解的状态信息
if status_flags & SERVER_SESSION_STATE_CHANGED {
string<lenenc>
session_state_changes
session state info
}
} else {
string<lenenc>
info
容易理解的状态信息
}
header：表明这是一个OK还是EOF响应。
capabilities ：在创建连接阶段，客户端和服务端交换的字段，用于表示支持哪些特性。
CLIENT_PROTOCOL_41：4.1+版本的客户端使用的协议。
ERR_Packet
Type Name Description
int<1>
header
[ff]
int<2>
error_code
错误码
if capabilities & CLIENT_PROTOCOL_41 {
string[1]
sql_state_marker
# marker of the SQL State
string[5]
sql_state
SQL State
}
string<EOF>
error_message
容易理解的错误信息
以上是 MySQL通讯协议（2）数据包 的全部内容， 来源链接： utcz.com/z/532942.html
