数据库连接数过多本质是连接泄漏或滥用，需先区分OS层TCP连接异常还是DB层会话超限：用ss命令查TCP连接数，再用SQL查DB会话数，结合来源IP、进程及socket数量定位泄漏源，重点关注CLOSE_WAIT和TIME_WAIT状态成因。
数据库连接数过多，本质是连接没释放或被滥用，不是“连太多”本身有问题，而是背后存在泄漏、配置失当或攻击。必须分层确认：是操作系统看到的 TCP 连接异常，还是数据库内部会话真超限？两者排查路径完全不同。
查清是 OS 层 TCP 连接爆了，还是 DB 层会话超限
先明确问题归属，避免在错误层面折腾：
- 运行
ss -tn state established | grep :1521 | wc -l（Oracle 默认端口）或ss -tn state established | grep :3306 | wc -l（MySQL），看真实 TCP 连接数。若远高于业务预期（比如 Web 服务下 MySQL 出现 5000+ ESTABLISHED），说明网络层已堆积 - 登录数据库执行对应查询：
SELECT COUNT(*) FROM v$session WHERE status='ACTIVE'（Oracle）或SHOW STATUS LIKE 'Threads_connected'（MySQL）。若该值接近processes（Oracle）或max_connections（MySQL）上限，才是 DB 层真超限 - 若 OS 层连接数高但 DB 层会话数低，大概率是客户端建连后没发请求就挂起（如空闲连接池未回收、爬虫握手即断），或中间件（如 HAProxy、Nginx）与 DB 之间连接未复用
- 若两者都高且同步增长，重点查应用是否未归还连接（如 Java 没 close()、Python requests 没用 session 或 connection pooling）
定位占用连接最多的客户端 IP 和进程
光看总数没用，得知道谁在连、怎么连、连了多久：
- 快速聚合来源 IP：
ss -tn state established | grep :1521 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10。若某 IP 占比极高，检查其行为是否合理（如定时任务未限频、客户端重试逻辑失控） - 查本地哪个进程在连 DB：
ss -tunlp | grep :1521（需 root）。输出中pid/program列直接给出进程 ID 和名称，比如24567/java或1892/mysqld - 进一步确认该进程打开的 socket 数量：
ls -l /proc/24567/fd/ | grep socket | wc -l。若远高于其应有连接池大小（如 HikariCP 配置了 maxPoolSize=20，却打开 300+ socket），基本可判定连接泄漏 - 注意：
lsof -i -n -P -p 24567也能列出所有网络句柄，但比ss -tunlp慢，且在高负载下可能卡住
CLOSE_WAIT 大量存在？十有八九是应用代码没关 socket
CLOSE_WAIT 是最危险的状态之一——它表示数据库已发 FIN 关闭连接，你的应用进程却一直没调 close()。内核完全无法干预，纯属应用层 bug：
- 用
ss -tn state close-wait | grep :1521 | wc -l确认数量。持续 >100 就要立即处理 - 定位到对应进程后，立刻检查日志：是否有
IOException、SocketTimeoutException、Connection reset等未捕获异常导致 finally 块跳过关闭逻辑 - Java 场景下，确认是否用了 try-with-resources；Python 中是否用
with conn.cursor():；Go 是否 deferrows.Close()。任何分支（包括 return、throw、panic）都必须保证资源释放 - 临时验证：用
strace -p 24567 -e trace=close,recv,send观察进程是否卡在recv()调用上，迟迟不进入close()
TIME_WAIT 过多？别急着改内核参数，先看是不是短连接滥用
TIME_WAIT 本身不是故障，是 TCP 正常机制。但大量出现往往暴露架构问题：
- 统计：
ss -tn state time-wait | grep :1521 | wc -l。若单机长期 >30000，结合cat /proc/sys/net/ipv4/ip_local_port_range（如输出1024 65535），说明可用端口已近耗尽，可能出现Cannot assign requested address错误 - 优先从应用层优化：数据库客户端必须启用连接池（如 HikariCP 的
maximumPoolSize+connection-timeout），禁用autoReconnect=true类伪健壮逻辑；HTTP 调用 DB 的中间层（如 API 网关）必须开启 Keep-Alive 并复用下游连接 - 仅当确认是客户端角色（如 ETL 工具、监控探针）高频建连时，才考虑开
net.ipv4.tcp_tw_reuse = 1（需同时确保net.ipv4.tcp_timestamps = 1）；服务端角色（如 Oracle Listener）开这个参数无效 -
net.ipv4.tcp_tw_recycle已从 Linux 4.12+ 移除，任何文档还在提它，都是过时信息，切勿配置
真正难处理的从来不是数字本身，而是那些 CLOSE_WAIT 状态里藏着的未关闭 finally 块、那些 ESTABLISHED 背后没设超时的 HTTP 客户端、以及把 max_connections 调到 10000 却不配连接池的应用配置。状态分布和进程绑定，永远比“重启服务”更能直击根因。
