mysqldump直接连库会大量占用连接，因默认每表建新连接且长期持有；应改用socket直连、限制backup账号max_user_connections、调低wait_timeout，并避免--compress和-h localhost。
备份脚本直接连库会吃掉大量连接
mysqldump 默认每个表单独建连接（尤其加了 --single-transaction 或 --lock-tables），遇到大库、多表、慢查询时，可能瞬间拉起几十甚至上百个并发连接。这些连接在备份期间全程保持活跃，不释放，直接挤占 max_connections 剩余配额。
实操建议：
- 用
--skip-lock-tables避免显式锁表（配合--single-transaction已足够） - 加
--no-autocommit+--skip-extended-insert降低单次事务体积，减少长事务阻塞 - 禁用
--compress（压缩在客户端做，反而增加连接生命周期） - 绝对不要在备份命令里写
-h localhost—— 这会强制走 TCP，绕过 socket 直连，多一层连接开销
mysqldump 的 --limit 和 --where 不解决连接数问题
--where 或 --limit 只控制导出数据量，不影响连接行为；它不会减少连接数，也不会缩短连接存活时间。哪怕只 dump 一行，只要用了 --single-transaction，就会启一个新连接并 hold 到整个 dump 结束。
真正有效的限流方式只有两种：
- 用
--parallel（Percona XtraBackup 支持，原生 mysqldump 不支持）—— 但注意：并行度 = 连接数，必须严格 ≤ 应用剩余连接池余量 - 用
ionice -c2 -n7+renice -n 19降权，避免备份 I/O 拖慢查询，间接减少慢查询堆积引发的连接卡死 - 最稳妥的是加
--sleep（需 patch 版本）或外层用sleep控制节奏，例如每 dump 5 张表后sleep 2
非业务高峰期仍暴增？检查 backup 用户的 max_user_connections
即使在凌晨执行，如果备份账号没设连接上限，它可能独占全部连接。执行：SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'backup';，若返回 -1（不限制）或远高于合理值（如 >20），立刻限制：
ALTER USER 'backup'@'%' WITH MAX_USER_CONNECTIONS 15;
同时确认该用户没被授予 SUPER 权限——否则 max_user_connections 生效但会被绕过。
额外提醒：MySQL 8.0+ 的 admin_port 不对备份流量豁免，别指望靠它救急。
真正安全的备份连接管理：用 socket + 专用账号 + wait_timeout 缩短
不要让备份走网络栈，改用本地 socket 直连：mysqldump -u backup -p -S /var/lib/mysql/mysql.sock ...。再配合运行时临时压低超时：
mysql -u root -p -S /var/lib/mysql/mysql.sock -e "SET SESSION wait_timeout = 60; SET SESSION interactive_timeout = 60;"
然后在同一 session 中跑 dump（或用 --defaults-file 绑定配置）。这样即使某张表 dump 卡住，60 秒后连接自动断，不会无限滞留。
容易被忽略的一点：wait_timeout 对 mysqldump 生效的前提是它没显式设置 AUTOCOMMIT=0 并长期 hold 事务——而默认就是这么干的。所以必须配合 --single-transaction 的合理性验证（比如确保 innodb_buffer_pool_size 足够，避免事务内触发磁盘临时表）。
