mysql拒绝新连接主因是内核listen队列满（net.core.somaxconn默认仅128），非max_connections不足；需同步调大somaxconn≥max_connections×1.2并持久化。
max_connections 设置后为什么新连接还是被拒绝
MySQL 拒绝新连接，不一定是 max_connections 没调够——更可能是操作系统级连接队列已满。MySQL 的 TCP 连接请求先由内核的 listen() 队列缓冲，这个队列长度由 net.core.somaxconn 控制，而非 MySQL 自身配置。
- Linux 默认
net.core.somaxconn通常只有 128，高并发短连接场景下极易溢出，表现为客户端报错Connection refused或卡在 SYN_RECV 状态 - 必须同时调大系统参数：
sudo sysctl -w net.core.somaxconn=65535，并写入/etc/sysctl.conf持久化 -
max_connections是 MySQL 内部线程/连接资源上限，而somaxconn是内核接收连接的“门廊宽度”，两者要匹配：建议somaxconn ≥ max_connections × 1.2
wait_timeout 和 interactive_timeout 区别在哪
这两个参数控制空闲连接自动断开时间，但触发条件完全不同，混用会导致连接意外中断。
-
wait_timeout作用于非交互式连接（比如 PHP-FPM、Java 应用通过 JDBC 建立的连接） -
interactive_timeout只对启用了CLIENT_INTERACTIVE标志的连接生效（典型如 mysql 命令行客户端） - 应用连接池（如 HikariCP）默认不设 interactive 标志，所以只受
wait_timeout影响；若该值设得太小（如 60 秒），连接池维护的长连接可能被 MySQL 主动 kill - 建议统一设为相同值（如 28800 秒 / 8 小时），并在应用侧做好连接有效性检测（如
testOnBorrow）
大量 TIME_WAIT 连接导致端口耗尽怎么办
TIME_WAIT 是 TCP 正常状态，但短连接高频建连/断连时，会快速占满本地端口范围（默认 32768–65535），表现为 Cannot assign requested address 错误。
- 不要盲目开启
net.ipv4.tcp_tw_reuse：它仅对客户端有效，MySQL 服务端作为 server 不适用此优化 - 优先从应用层减少连接频次：启用连接池、复用连接、避免脚本里循环
mysql_connect() - 确需调优时，可适当缩小
net.ipv4.ip_local_port_range范围（如设为1024 65535），并确保net.ipv4.tcp_fin_timeout≤ 30（缩短 TIME_WAIT 持续时间） - 注意：
tcp_tw_recycle已在 Linux 4.12+ 移除，且在 NAT 环境下有严重风险，禁止使用
performance_schema 中哪些表能直接反映连接排队情况
光看 Threads_connected 或 Aborted_connects 不够，真正体现“排队堵点”的是底层等待事件和 socket 状态。
- 查当前是否有连接在内核队列中等待：
SELECT * FROM performance_schema.socket_summary_by_event_name WHERE event_name LIKE 'wait/io/socket/%' AND COUNT_STAR > 0; - 观察连接建立耗时异常：
SELECT EVENT_NAME, AVG_TIMER_WAIT FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME = 'wait/io/socket/sql/server_unix_socket' OR EVENT_NAME = 'wait/io/socket/sql/server_tcpip_socket';，若平均等待超 10ms，说明 listen 队列或线程调度存在压力 -
SHOW PROCESSLIST里出现大量Sleep状态但Time值持续增长，往往是连接池未正确回收，而非并发配置问题
真正卡住的地方往往不在 MySQL 配置本身，而在系统网络栈、应用连接管理、甚至云厂商安全组连接跟踪表（conntrack）限制。调参前先确认瓶颈在哪一层。
