MySQL连接超时不是单一原因导致的问题，而是数据库、网络、应用三端协同失配的结果。解决的关键在于分层定位：先确认是“连不上”，还是“连上了但执行慢/断开”，再针对性处理。
检查并修复网络与基础连通性
很多超时问题其实卡在第一步——根本没通到数据库。
用 ping 和 telnet your_mysql_ip 3306（或 nc -zv）验证服务器可达性和端口开放状态 检查服务器防火墙（如 ufw、iptables）是否放行 3306 端口 确认 MySQL 配置中 bind-address 是否设为 0.0.0.0 或具体允许访问的 IP，而非仅限 localhost 如果是云服务器，额外检查安全组规则是否授权对应 IP 段访问调整 MySQL 服务端超时参数
默认 8 小时空闲断连对多数 Web 应用偏长，反而容易因中间网络波动引发意外中断。
编辑 my.cnf（Linux）或 my.ini（Windows），在 [mysqld] 下设置： wait_timeout = 600（单位秒，建议 300–1800） interactive_timeout = 600（影响交互式客户端，保持与 wait_timeout 一致） max_connections = 500（根据并发量合理上调，避免连接数耗尽后新请求排队超时） 修改后执行 sudo systemctl restart mysql 生效应用端必须做连接管理优化
服务端调参只是辅助，真正稳定靠应用层主动维护连接生命周期。
禁用全局单例 connection 对象；改用 连接池（Connection Pool），例如 Node.js 的mysql.createPool、Java 的 HikariCP、Python 的
mysql-connector-python连接池模式 连接池配置中启用 testOnBorrow 或 validationQuery=SELECT 1，确保取出连接前已校验有效性 对长周期任务，避免一个事务或连接占用过久；执行完及时 close() 或归还连接池 客户端连接 URL 中可显式加参数，如 JDBC：
?autoReconnect=true&socketTimeout=30000；Node.js：
connectionLimit: 10, acquireTimeout: 10000
排查慢查询与锁竞争根源
表面是“连接超时”，实际常因某条 SQL 执行太久、持锁不放，拖垮整个连接队列。
开启慢查询日志：slow_query_log = ON，
long_query_time = 1，定期分析
mysqldumpslow输出 执行
SHOW PROCESSLIST;查看当前阻塞会话，重点关注 State 为 Sending data、Locked、Updating 且 Time 值异常高的线程 对高频 WHERE 条件字段（如
AD_BI_NO）添加索引：
CREATE INDEX idx_wf_approve_ad_bi_no ON wf_approve(AD_BI_NO);，把表级锁降为行级锁 避免在事务中做 HTTP 请求、文件读写等外部耗时操作
