查错误日志路径：先确认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 配置本身，而在于你根本不知道网络链路上还有几个“隐形超时开关”在默默倒计时。
