net_read_timeout控制MySQL服务端从客户端读取数据的超时上限，非空闲断开或建连超时；设太小致大查询中断，设太大致线程卡死；wait_timeout对其无效，合理值依场景定：Web API用30–45秒，ETL用300秒，离线分析可至1800秒，但须配合应用层超时且禁用0值。

net_read_timeout 控制的是 MySQL 服务端从客户端读数据的等待上限，不是连接空闲断开时间，也不是建连握手超时；设太小会导致大查询、mysqldump 或长事务中途断连，设太大又可能让异常连接卡住线程不释放。

为什么改了 wait_timeout 却没解决 “Lost connection during query”

这是最常踩的坑：很多人遇到 Lost connection to MySQL server during query 就去调 wait_timeout，结果白忙。因为 wait_timeout 只管“连接空闲多久断”，而大查询执行中是活跃状态，它根本不会触发。真正起作用的是 net_read_timeout——比如客户端在发一个巨长的 INSERT 或 COMMIT 大事务时卡住了，服务端等不到后续数据包，就按这个值超时断开。

• 现象：执行 INSERT ... SELECT 或批量导入时突然中断，SHOW PROCESSLIST 里看到线程状态是 Reading from net
• 日志里常伴随 Got timeout reading communication packets
• wait_timeout 和 interactive_timeout 对这类问题完全无效

怎么设 net_read_timeout 才合理

不能拍脑袋定值，得看真实负载场景：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 普通 Web API（单次查询秒级）：保持默认 30，或微调到 45 即可
• 报表/ETL/后台导出任务：建议设为 300（5 分钟），mysqldump 导大表基本够用
• 离线分析类超长任务：可设 1800（30 分钟），但必须配合应用层超时控制，避免线程堆积
• 绝对不要设为 0（禁用超时）：MySQL 会一直阻塞等待，线程无法释放，最终耗尽 max_connections

修改后只对新建立的连接生效，老连接仍沿用旧值，无需重启 MySQL，但需滚动更新连接池或等自然淘汰。

net_read_timeout 和客户端 socketTimeout 怎么配合

两者叠加生效，但触发层级不同，容易互相掩盖问题：

• socketTimeout（如 JDBC 的 socketTimeout=30000）是驱动层控制「单次 TCP read 操作」超时，单位毫秒
• net_read_timeout 是服务端内核级控制「整个数据包接收过程」超时，单位秒
• 如果 socketTimeout 先触发，应用报 Communications link failure
• 如果 net_read_timeout 先触发，服务端主动断连，应用可能收 EOFException 或空结果
• 推荐：客户端 socketTimeout 设为略小于服务端 net_read_timeout，留 10–20 秒缓冲（例如服务端设 300，客户端设 28000）

真正难处理的不是设多少，而是当 net_read_timeout 被其他配置覆盖时你根本不知道——比如某些云数据库控制台会屏蔽该参数，或被中间件代理悄悄重写。上线前务必用 SHOW VARIABLES LIKE 'net_read_timeout'; 和实际压测验证，别只信配置文件。