MySQL客户端发一条SQL，底层先封装为一个≤max_allowed_packet的逻辑packet（含4字节头部），再由TCP栈分段为多个IP包；超限直接报错，不自动切分或重试。
MySQL客户端发一条SQL，底层怎么拆成TCP包
不是“一条SQL → 一个TCP包”，而是“一条SQL → 一个MySQL逻辑packet（≤max_allowed_packet）→ 可能被TCP栈拆成多个IP包”。MySQL协议本身不干预TCP分段，只保证单个逻辑packet结构完整。
关键约束在max_allowed_packet：SQL文本长度 + 协议头（3字节长度字段 + 1字节序列号）必须 ≤ 该值，否则直接报错 Packet too large。驱动不会帮你切分或重试。
- 如果SQL总长 3.8MB，
max_allowed_packet=4M→ 打成1个MySQL packet，但TCP可能拆成3–5个IP包（你无需感知） - 如果SQL总长 5MB，
max_allowed_packet=4M→ 驱动立刻抛异常，不会发到网络层 - Java的
mysql-connector-java在useServerPrepStmts=true时，prepare语句的元数据也受同一限制
抓包看到连续多个00 00 00开头的TCP流，是重传吗
不是重传，是正常协议行为。MySQL packet头部是3字节小端长度 + 1字节序列号；长度为0的包（如心跳、空认证响应）就表现为00 00 00 + 序列号（00、01、02…）。
真正要警惕的是：同一逻辑请求发出后，Wireshark里出现两次非零长、内容高度相似的packet（比如都以08 00 00开头），那才可能是连接异常触发了客户端重发——但这属于驱动层容错，和MySQL协议无关。
- 序列号从0开始递增，到255后回绕到0，不重置
- 服务端收到序列号乱序（如收到seq=2但没收到seq=1），会等或直接断连，不自动重排
- 用Wireshark过滤
mysql && tcp.seq == 2却没看到对应响应，大概率是丢包或超时
MySQL协议里“长度编码字符串”怎么识别
MySQL不用C风格的\0结尾，而是把长度明文写在数据前面，叫Length Coded String。解包时先读第一个字节判断长度字段占几字节：
-
len < 251→ 长度就存这1字节，后面紧跟字符串 -
len == 252→ 后续2字节是真实长度（小端） -
len == 253→ 后续3字节是真实长度 -
len == 254→ 后续8字节（小端）是真实长度（注意：不是4字节）
例如字段名user_id在网络包里不会以75 73 65 72 5F 69 64 00形式出现，而是类似07 75 73 65 72 5F 69 64（首字节07表示后续7字节是字符串内容）。
压缩传输开启后，封包结构变了吗
开启压缩（CLIENT_COMPRESS标志位为1）后，MySQL packet结构不变，只是在消息体层面多了一层zlib压缩。服务端和客户端协商成功后，所有后续packet（包括COM_QUERY、结果集等）都会被压缩，但头部4字节（3字节长度+1字节序列号）仍明文传输。
- 压缩前：整个payload（含命令码+SQL）被zlib压缩，再填入packet body
- 压缩后：packet length字段反映的是压缩后的字节数，不是原始SQL长度
- 抓包看到长度很小但内容不可读，大概率开启了压缩；Wireshark需启用MySQL解码并勾选“decompress”才能还原
- 压缩不改变协议状态机，也不影响
max_allowed_packet的校验时机（校验发生在解压后）
net_field_length、net_store_length这些C函数里，但实际调试时，真正卡住你的往往不是格式，而是max_allowed_packet设大了导致单次接收延迟飙升，或者忘了压缩开关让抓包看起来像乱码。 
