Linux中判断数据库连接是否超时中断，核心是结合客户端退出码、stderr关键词（如“timed out”）、服务端连接状态（如MySQL的TIME字段）、系统级网络状态（ss/netstat/tcpdump）及数据库超时参数（如wait_timeout）综合识别，而非仅依赖Shell条件语句。
看客户端命令的退出状态和错误输出
使用 mysql、psql、redis-cli 等工具尝试简单操作（如执行 SELECT 1 或 PING），再检查其退出码和 stderr：
- 退出码非 0（如 1 或 2）通常表示连接失败或查询异常
- stderr 中出现 "Connection timed out"、"Lost connection"、"Read timed out"、"Operation timed out" 等关键词，基本可判定超时中断
- 示例脚本片段：
if ! mysql -h 192.168.1.100 -P 3306 -u test -ptestdb -e "SELECT 1" 2>/tmp/mysql_err.log; then
if grep -q "timed out\|lost connection" /tmp/mysql_err.log; then
echo "数据库连接已超时或中断"
fi
fi
查数据库服务端连接状态与空闲时间
在数据库服务器本地，可通过系统视图或命令观察连接是否因超时被主动断开：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- MySQL：查 information_schema.processlist 中 TIME 字段（单位秒），若远超 wait_timeout 或 interactive_timeout 值，但状态仍为 Sleep，说明可能已被服务端强制关闭（下次操作会报错）
- PostgreSQL：查 pg_stat_activity 的 state 和 backend_start / state_change 时间差，结合 tcp_keepalives_idle 配置判断是否因网络空闲超时断连
- Redis：用 redis-cli info clients | grep connected_clients 结合 netstat -an | grep :6379 | grep ESTABLISHED | wc -l 对比，若差异大，可能有连接被内核或中间件超时回收
抓包或检查系统级连接状态
当应用层无明确报错，但业务偶发失败时，可在服务端用网络工具确认连接是否真实存活：
- 运行 ss -tuln | grep :3306 或 netstat -tnp | grep :5432，看连接是否处于 ESTABLISHED 状态
- 对可疑连接执行 ss -ti（显示 TCP 详细信息），观察 retrans（重传）、rto（超时时间）、last_ack（最后确认时间）等字段是否异常
- 用 tcpdump 抓包过滤目标端口，查看是否有 FIN/RST 包突然出现，表明连接已被某端主动终止
依赖数据库自身的超时参数与日志
连接是否“被超时”，最终取决于服务端配置和网络环境。需核对关键参数：
- MySQL：wait_timeout（非交互连接默认 28800 秒）、connect_timeout（握手超时，默认 10 秒）
- PostgreSQL：tcp_keepalives_idle、tcp_keepalives_interval、tcp_keepalives_count
- Redis：timeout（客户端空闲 N 秒后关闭，默认 0 表示禁用）
- 所有数据库都应检查错误日志中是否含 "Aborted connection"、"Connection reset"、"Client closed the connection" 等记录
