错误日志路径需用SHOW VARIABLES LIKE 'log_error'确认，如/var/log/mysql/error.log；过滤aborted、timeout等关键词定位超时类型；关联wait_timeout等参数及中间网络设备超时设置。
查错误日志路径：先确认MySQL自己把日志写在哪
错误日志是排查超时问题的第一现场，但很多人连日志文件在哪都不知道。别猜，直接问MySQL：SHOW VARIABLES LIKE 'log_error';。返回值就是真实路径，比如 /var/log/mysql/error.log 或 /usr/local/var/mysql/hostname.err。如果MySQL根本起不来，就去默认位置盲找：Linux 看 /var/log/mysql/ 或数据目录下的 *.err 文件；macOS Homebrew 安装的通常在 /usr/local/var/mysql/。
搜关键错误模式：不是所有“timeout”都一样
打开日志后，用 grep -i "aborted\|timeout\|communication\|read\|write" 过滤，重点关注三类线索：
-
Aborted connection NNN to db: 'xxx' user: 'yyy' host: 'zzz'：服务端主动断开连接，大概率是wait_timeout或interactive_timeout触发的； -
Got timeout reading communication packets：客户端发包慢或网络卡顿，常与net_read_timeout相关； -
Lost connection to MySQL server during query或MySQL server has gone away：可能是查询执行中被中断，需结合慢查询日志交叉验证。
注意："Query timeout" 一般不会出现在错误日志里——那是应用层或驱动设置的，错误日志只记录服务端感知到的底层通信异常。
关联配置参数：看日志前先查服务端设置
光看日志不查配置，等于看症状不量血压。立刻执行：SELECT @@wait_timeout, @@interactive_timeout, @@net_read_timeout, @@net_write_timeout, @@connect_timeout;。常见陷阱：
-
wait_timeout设成 300（5分钟）却让连接池空闲保持 10 分钟，必然触发Aborted connection； -
net_read_timeout默认 30 秒，但若应用执行大事务或导出操作，中途网络抖动几秒就可能被断； -
connect_timeout太小（如 2 秒）会导致高延迟网络下新连接直接失败，报错2003: Can't connect to MySQL server，容易误判为服务宕机。
这些参数改完必须重启 MySQL 或用 SET PERSIST（8.0+）使其持久化，仅 SET GLOBAL 在重启后失效。
排除中间链路干扰：防火墙、云网关、负载均衡器才是真凶
很多“MySQL超时”根本不是 MySQL 的锅。云厂商 NAT 网关、阿里云 SLB、AWS ALB、甚至公司内网防火墙，普遍设了 5 分钟（300 秒）空闲 TCP 超时。只要连接期间没数据交互，中间设备会静默发 RST 包，MySQL 和客户端都以为对方崩了。
验证方法很简单：tcpdump -i any port 3306 -w mysql_timeout.pcap 抓包复现一次超时，然后用 Wireshark 打开，看最后是不是有来自非 MySQL 主机的 RST 包。如果是，就得调中间设备的 idle timeout，或者让客户端启用 TCP keepalive（如 Java 的 socket.setKeepAlive(true)），并配合连接池的 validationQuery=SELECT 1 主动保活。
真正难缠的点从来不在 MySQL 配置本身，而在于你根本不知道网络链路上还有几个“隐形超时开关”在默默倒计时。
