“reading from network failed”是mysql服务已接受连接但在数据读取阶段中断的网络层错误，主因是net_read_timeout过短、中间设备超时、dns解析阻塞（需启用skip-name-resolve）或客户端异常退出，与权限及密码无关。
“Reading from network failed” 是网络层中断信号，不是权限或密码问题
这个错误说明 MySQL 服务进程已接受连接，但在后续数据读取阶段收不到客户端发来的完整包。它和 Access denied、Connection refused 本质不同——前者是认证失败，后者是连不上，而这个是“连上了却断在半路”。常见于高延迟、丢包、中间设备（如 NAT 网关、负载均衡器）超时踢连接，或客户端异常退出未发 FIN 包。
检查 net_read_timeout 和 wait_timeout 配置是否过短
MySQL 默认的 net_read_timeout 是 30 秒，wait_timeout 是 28800 秒（8 小时）。如果客户端发送请求后长时间没发后续数据（比如大查询结果未及时 fetch、长事务未提交），服务端可能直接关闭 socket，日志里就记为 “Reading from network failed”。
实操建议：
- 登录 MySQL 后执行
SHOW VARIABLES LIKE 'net_read_timeout';和SHOW VARIABLES LIKE 'wait_timeout';查当前值 - 若业务有批量导出、ETL 或慢查询场景，把
net_read_timeout提到 120～300（单位：秒），写进配置文件my.cnf的[mysqld]段下 - 注意：修改后必须重启 MySQL 或用
SET GLOBAL net_read_timeout = 300;（临时生效，重启丢失） - 不要盲目调高
wait_timeout，它影响空闲连接保活，过高会积压大量僵尸连接
排查中间网络设备主动断连
云厂商 SLB、企业防火墙、K8s Service 的 conntrack 表、甚至某些路由器都默认对“静默 TCP 连接”设 5～30 分钟超时。一旦连接空闲超过该阈值，设备会单方面发 RST，MySQL 就报这个错。
验证与应对：
- 用
tcpdump -i any port 3306 -w mysql.pcap抓包，过滤出异常断连时刻的 RST 包来源 - 在云控制台查 LB/安全组的“空闲连接超时”设置（阿里云叫
IdleTimeout，腾讯云叫ConnectionIdleTime），确保 ≥ MySQL 的wait_timeout - 客户端代码里加心跳：例如 Python 的
mysql-connector-python可设connection_timeout=30+ 定期执行SELECT 1 - 避免在长事务中做耗时计算；改用分页或流式 fetch 处理大结果集
skip-name-resolve 必须开启，否则反向 DNS 查询会拖垮读取
当 MySQL 收到新连接，若未设 skip-name-resolve，它会对客户端 IP 做反向 DNS 解析。一旦 DNS 不稳定或超时（比如解析到 *.*.*.*.bc.googleusercontent.com 这类可疑域名），整个连接卡住，后续读操作就会失败并报 “Reading from network failed”。
关键动作：
- 确认配置文件
my.cnf的[mysqld]段里有skip-name-resolve（注意：不是skip_name_resolve，下划线错就无效） - 删掉或注释掉已有的
bind-address行再重启，避免因 bind 地址和 skip-name-resolve 冲突导致启动失败 - 重启后执行
SELECT @@skip_name_resolve;返回 1 才算生效 - 用户表里所有
host字段必须用 IP 或%，不能再依赖主机名（如'user'@'webserver.local'会失效）
真正棘手的是它常和网络抖动、DNS 延迟、中间设备策略耦合发生，单看日志很难定位。抓包 + 查 MySQL error log + 对比云平台连接超时设置，三者缺一不可。别只改 MySQL 参数就以为解决了。
