短连接吃光本地端口是因为客户端每秒高频建连导致TIME_WAIT堆积，60秒内占满默认32768个端口，引发“Cannot assign requested address”；MySQL的wait_timeout等参数对此无效，必须在客户端系统层启用tcp_tw_reuse、扩大ip_local_port_range并谨慎调小tcp_fin_timeout，或根本性采用连接池复用长连接。
短连接为什么吃光本地端口（TIME_WAIT堆积）
不是MySQL服务端先扛不住，而是客户端机器的可用端口被快速占满、无法新建连接。Linux默认net.ipv4.ip_local_port_range是 32768–65535（共约 32768 个端口），而每个短连接断开后会进入 TIME_WAIT 状态，持续 2×MSL（通常 60 秒）。若每秒建连 500 次，1 分钟内就产生 3 万个 TIME_WAIT 连接，端口池直接见底，新连接报错 Cannot assign requested address。
MySQL服务端参数对端口回收毫无作用
很多人误以为调小 wait_timeout 或 interactive_timeout 能缓解端口耗尽——其实完全没用。这两个参数只控制 MySQL 主动关闭空闲连接的时间，不影响 TCP 层的四次挥手和 TIME_WAIT 生命周期。客户端发起 close() 后，端口是否可重用，只由客户端操作系统决定，MySQL 无权干预。
真正有效的三个动作
必须在客户端（应用服务器）操作系统层面操作，不能只改 MySQL 配置：
- 启用端口快速复用：
sysctl -w net.ipv4.tcp_tw_reuse=1（仅对客户端为 TIME_WAIT 的连接有效，且要求时间戳开启） - 降低 TIME_WAIT 持续时间（谨慎）：
sysctl -w net.ipv4.tcp_fin_timeout=30（不改变 MSL，但加速状态迁移） - 扩大端口范围：
sysctl -w net.ipv4.ip_local_port_range="1024 65535"（从 32k 扩到 64k，翻倍可用端口）
注意：tcp_tw_recycle 已在 Linux 4.12+ 移除，且 NAT 环境下会导致连接失败，切勿启用。
为什么连接池能绕过这个问题
连接池复用的是同一个 socket 连接，不会频繁创建/销毁 TCP 连接，自然不触发大量 TIME_WAIT。哪怕应用 QPS 达 2000，只要池大小稳定在 50，实际只维持 50 个长连接，端口占用恒定。这也是为什么所有高并发场景都强制要求用连接池——它本质是把“端口资源竞争”转化成了“连接复用管理”，把系统瓶颈从网络栈转移到了数据库线程调度上。
端口耗尽往往发生在未启用连接池、或连接池配置成 maxLifetime=0 + idleTimeout 过短的场景，此时连接被频繁重建，比业务逻辑本身还“勤奋”地消耗端口。
