先确认是否真连满：执行SHOW VARIABLES LIKE 'max_connections'查上限，SHOW STATUS LIKE 'Threads_connected'查当前连接数，若后者接近前者且Threads_running极低，说明大量连接卡在Sleep状态，多因应用未释放或连接池与MySQL超时参数错配。
别急着改 max_connections，90% 的 “Too many connections” 是连接没释放，不是上限太小——先确认是不是真满了，再动手。
怎么一眼看出是不是真连满了
哪怕应用连不上，MySQL 会预留一个 SUPER 权限的紧急连接位（max_connections + 1），所以你还能用 socket 直连进去查状态：
- 执行
SHOW VARIABLES LIKE 'max_connections';—— 看上限，默认常是 151 - 执行
SHOW STATUS LIKE 'Threads_connected';—— 看当前已建连数 - 执行
SHOW STATUS LIKE 'Threads_running';—— 看正在干活的线程数
如果 Threads_connected 接近上限，但 Threads_running 极低（比如 3/498），说明几百个连接全卡在 Sleep 状态，基本就是应用没关连接，或连接池 idleTimeout 比 MySQL 的 wait_timeout 还长。
为什么 SET GLOBAL max_connections 经常不生效
这条命令看着快，实际有三道硬门槛拦着：
- Linux 系统级文件描述符限制：运行
ulimit -n，默认常为 1024；设到 1000 就可能失败。Docker 容器里没加--ulimit nofile=65536:65536，光改 MySQL 配置无效 - 已经连不上了？那这条命令根本执行不了——得靠
kill -TERM $(pgrep mysqld)（不是mysqld_safe）安全重启 - 内存扛不住：每个连接平均吃 512KB～2MB，设到 2000 连接，光连接本身就要 1～4GB 内存，容易触发 OOM
验证是否生效，别信配置文件，要查运行时值：SELECT @@global.max_connections;
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
怎么定位“占着茅坑不拉屎”的连接
SHOW PROCESSLIST; 是核心诊断命令，重点关注三类连接：
-
State = 'Sleep'且Time > 300：空闲超 5 分钟，基本是应用没关连接或连接池配置失当 -
State = 'Sending data'或'Locked'且Time持续增长：SQL 卡住了，可能是慢查询、锁等待或大事务 - 同一
User+Host出现几十个连接：大概率是某个应用实例泄漏，比如 PHP 脚本异常退出未归还连接
注意：SHOW PROCESSLIST 默认只显示当前用户权限下的连接；查全量需用 root 或具备 PROCESS 权限的账号，否则看不到其他应用的连接。
连接池 idleTimeout 和 MySQL wait_timeout 必须对齐
多数线上事故根子在应用侧。比如 HikariCP 或 Druid，常见错配：
-
maximumPoolSize（或max-active）设得比max_connections还高，多个服务一起压就爆 -
idleTimeout（连接池） >wait_timeout（MySQL），导致连接池以为连接还活着，MySQL 却已单方面断开，后续复用时报错或卡死 -
wait_timeout和interactive_timeout值不一致：很多 DBA 只改了前者，后者仍为 8 小时，结果交互式客户端连接长期不释放
正确做法是：连接池 idleTimeout 必须 ≤ MySQL 的 wait_timeout，建议都设成 300 秒（5 分钟）起手，再根据业务微调。
最易被忽略的一点是：wait_timeout 和 interactive_timeout 必须同时调，且值一致。很多 DBA 只改了前者，后者仍为 8 小时，结果交互式客户端连接长期不释放——这会让问题在夜间或低峰期悄悄发酵，直到某次高峰突然爆发。
