直接检查MySQL错误日志中“Aborted connection”记录，可快速定位连接中断原因：若含“Got an error reading communication packets”，多为客户端异常断开或网络丢包；若含“because of wait_timeout”，属服务端空闲超时；若含“because of net_read_timeout”，则可能因大结果集或慢查询导致读响应超时。
查 MySQL 错误日志里有没有 “Aborted connection” 记录
这是最直接的线索。MySQL 每次主动断开连接，只要没被静默忽略，基本都会在错误日志里记一笔 Aborted connection，并附带原因和时间戳。
执行：tail -n 200 /var/log/mysql/error.log（路径依系统而异，Docker 容器里可能是 /var/lib/mysql/hostname.err）
重点关注三类信息：
- “Got an error reading communication packets” —— 很可能客户端提前断了或网络丢包
- “Aborted connection … because of wait_timeout” —— 服务端空闲超时杀连接
- “Aborted connection … because of net_read_timeout” —— 查询执行中读取响应超时，常对应大结果集或慢查询
如果日志里没看到这些，说明断连发生在 TCP 层（比如防火墙、ALB、NAT 设备发了 RST），得换抓包或中间件日志查。
对比 net_read_timeout 和实际查询耗时
net_read_timeout 控制的是“服务器等待客户端读取响应的时间”，不是查询执行时间本身。但当查询返回巨大结果集（比如百万行、大 BLOB）时，客户端消费速度慢，服务端等不及就断。
确认当前值：SHOW VARIABLES LIKE 'net_read_timeout';（默认 30 秒）
验证是否触发：
- 用
EXPLAIN看执行计划，估算扫描行数和临时表大小 - 在客户端加
--verbose或开启 PyMySQL 的debug=True，观察从 query 开始到报错之间的真实耗时 - 如果耗时接近
net_read_timeout值（比如 28–32 秒），大概率就是它卡住的
临时调高可验证：SET SESSION net_read_timeout = 600;（注意：GLOBAL 修改需权限，且不作用于已存在的连接）
检查 max_allowed_packet 是否小于结果集
这个参数限制单次传输的数据包上限。一旦查询返回的某一行或整个结果集超过该值，MySQL 会直接中断连接，报错里有时会顺带提示 ER_NET_PACKET_TOO_LARGE。
查当前设置：SHOW VARIABLES LIKE 'max_allowed_packet';（默认 4MB）
典型踩坑场景：
- 导出的 SQL 文件含超长
INSERT ... VALUES (...),(...),...语句，整条语句体积 > 4MB -
SELECT *查含MEDIUMTEXT或多个BLOB字段的表，单行就超限 - 客户端驱动（如 PyMySQL）没设
max_allowed_packet，和服务端不一致，解析失败
安全调整方式：SET GLOBAL max_allowed_packet = 512 * 1024 * 1024;（512MB），但要同步改配置文件 my.cnf 的 [mysqld] 段，否则重启失效。
别只盯着 MySQL 配置，先看中间链路有没有更短的超时
很多生产环境 MySQL 前面有 HAProxy、AWS ALB、TaoToken 通道、K8s Service 等。它们的空闲超时（idle timeout）往往比 MySQL 的 wait_timeout 还短——比如 ALB 默认 60 秒，而你把 wait_timeout 调到 8 小时也没用，连接早被 ALB 清掉了。
排查动作：
- 确认客户端到 MySQL 之间是否存在代理/网关
- 查该中间件的 idle timeout 设置（例如 ALB 的
idle_timeout.timeout_seconds） - 如果用了统一通道（如 TaoToken），检查其 DB 连接池的
pool_recycle或保活心跳是否开启
真正麻烦的不是参数调不对，而是各层超时值互相打架：MySQL 认为连接还活着，中间件认为该回收了，客户端还认为能复用——三边认知不一致，断连就成了随机事件。
