mysql客户端sql经驱动按“长度前缀+数据体”封装为单个逻辑packet（≤max_allowed_packet），由tcp负责分段；超限直接报错，不自动切分；协议无重传，依赖tcp可靠性。
MySQL客户端发一条SQL，底层怎么拆成TCP包
MySQL用的是自定义应用层协议（不是http那种），所有请求/响应都按“长度前缀 + 数据体”打包。每次发送不等于一次TCP send()，MySQL驱动会自己缓冲、分包、粘包处理——你看到的mysql_real_query()调用，背后可能触发多次send()系统调用，也可能合并多个小查询一起发。
关键点：协议本身不关心TCP分段，只保证单个“报文”（packet）内部结构完整。一个逻辑上的MySQL packet最大是max_allowed_packet（默认4MB），超过就直接报错Packet too large，不会自动切分。
- 如果SQL文本 + 协议头（4字节长度字段） ≤
max_allowed_packet，整个SQL被打成1个MySQL packet，但可能被TCP栈拆成多个IP包（这层你不用管） - 如果参数里有超大BLOB，且总长超限，驱动通常不帮你截断或分片，而是直接抛异常
MySQL server has gone away（实际是写入失败） - Java的
mysql-connector-java默认启用useServerPrepStmts=true时，prepare阶段的语句描述也会走同一套封包逻辑，注意max_allowed_packet对元数据也生效
抓包看到多个“0x00 0x00 0x00”开头的TCP流，是MySQL在重试吗
不是重试，是正常协议行为。MySQL packet头部是3字节长度（little-endian）+ 1字节序列号。比如你看到连续几个包都以00 00 00开头，大概率是客户端在发“握手初始化包”或“空心跳包”，长度为0，序列号递增（00、01、02…）。序列号每发一个packet就+1，到255后回绕到0。
真正要警惕的是：同一个逻辑请求发出后，wireshark里出现重复的非零长packet（比如两次08 00 00开头的包内容几乎一样），那才可能是连接异常导致客户端重发——但这属于驱动层行为，和MySQL协议无关。
- MySQL协议本身无ACK机制，也不重传，可靠性全靠TCP
- 用
tcpdump -i any port 3306 -w mysql.pcap抓包后，用Wireshark过滤mysql协议层，比只看TCP更准 - 序列号字段只在同一次连接内有意义，服务端靠它识别是否丢包或乱序（例如收到
seq=2但没收到seq=1，会等或直接断连）
max_allowed_packet设太大，会导致网络包更多还是更少
设太大不会增加网络包数量，但会显著提高单次write()的内存拷贝开销和延迟风险。MySQL服务端收到一个超大packet后，必须等全部数据收完才开始解析——中间任何丢包或超时都会让整个packet作废，重传成本极高。
典型陷阱：把max_allowed_packet从4MB调到1GB，看似能塞下大json，结果在千兆网+高延迟链路上，单次接收耗时可能从1ms飙到200ms以上，触发客户端connect timeout或read timeout。
- 服务端配置
max_allowed_packet影响server端接收上限，客户端驱动也有自己的限制（如Python的pymysql默认是16MB，需显式设max_allowed_packet参数） - 批量INSERT时，拼接1000行比拼10000行更稳——不是因为包数量多，而是因为单包失败代价小，重试粒度可控
- 真正减少网络交互次数，靠的是
LOAD DATA INFILE或客户端批量API（如executemany()），而不是盲目调大max_allowed_packet
Go的database/sql执行Query时，packet封包逻辑谁控制
Go标准库不碰封包细节，全交给驱动。比如github.com/go-sql-driver/mysql，它在writeCommandPacket()里手动构造协议头，再调conn.write()。你传给db.Query()的SQL字符串，会被原样塞进packet body，前面补上4字节长度头和序列号。
这意味着：SQL里的换行、空格、注释，全都会计入packet长度。一个带200KB注释的视图创建语句，哪怕实际执行部分只有1KB，也会占满整个packet配额。
- 预编译语句（
Prepare()）的SQL模板在prepare阶段封一次包，Exec()时只封参数值（二进制协议下参数单独编码，不拼SQL字符串） - 如果用
context.WithTimeout()控制查询，超时发生在驱动等待服务端响应时，和封包过程无关；但超大packet会让“等待响应”的起点大幅延后 - 调试时想看真实封包内容，可在驱动源码
writePacket()函数里加log.printf("wire: %x", data)，别依赖mysql --verbose，它只显示逻辑层
事情说清了就结束