MySQL "Too many connections" 連接數耗盡完整排查與優化指南

錯誤 ERROR 1040 (HY000): Too many connections 表示當前活躍連接數達到 max_connections 上限。本文系統講解連接數監控、參數調優、連接池配置、應用層洩漏排查、緊急擴容五大維度，徹底解決連接耗盡問題。

一、 核心機制與關鍵變量

二、 實時監控與診斷

-- 1. 查看當前配置與狀態
SHOW VARIABLES LIKE 'max_connections';
SHOW GLOBAL STATUS LIKE 'threads_connected';
SHOW GLOBAL STATUS LIKE 'max_used_connections';
SHOW GLOBAL STATUS LIKE 'connection_errors_max_connections';

-- 2. 連接來源分析
SHOW PROCESSLIST;
-- 或詳細版
SELECT * FROM information_schema.PROCESSLIST ORDER BY TIME DESC;

-- 3. 按用戶/主機統計
SELECT USER, HOST, COUNT(*) AS conn_count
FROM information_schema.PROCESSLIST
GROUP BY USER, HOST
ORDER BY conn_count DESC;

三、 參數調優：調大 max_connections

1. 動態生效 (無需重啟)

SET GLOBAL max_connections = 3000;

2. 持久化配置 (my.cnf / my.ini)

[mysqld]
max_connections = 3000
# 相關配套調大
open_files_limit = 10000          # OS 文件描述符上限，需 ulimit -n 支援
table_open_cache = 2000           # 表緩存，防止頻繁開關表
max_user_connections = 2000       # 單用戶上限，防單點佔用

3. OS 級限制同步修改 (/etc/security/limits.conf)

mysql soft nofile 65535
mysql hard nofile 65535

重啟 MySQL 服務生效。

四、 根因分類與對應策略

五、 連接池最佳配置 (以 HikariCP / Druid / DBCP2 為例)

# HikariCP (Spring Boot 2+ 默認)
spring.datasource.hikari.maximum-pool-size=20        # 單實例池大小
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.idle-timeout=300000         # 5分鐘空閒回收
spring.datasource.hikari.max-lifetime=1800000        # 30分鐘強制換新
spring.datasource.hikari.connection-timeout=30000    # 獲取連接超時 30s
spring.datasource.hikari.leak-detection-threshold=60000 # 洩漏檢測 60s

原則： 總池大小 (實例數 × maximum-pool-size) ≤ max_connections × 80% (預留 20% 給管理/備份/監控連接)。

六、 緊急臨時擴容腳本 (不重啟)

#!/bin/bash
# 緊急將 max_connections 臨時調大至 5000
mysql -uroot -p -e "SET GLOBAL max_connections = 5000;"
# 同步調大 open_files_limit (需重啟生效，這裡僅作提醒)
echo "WARNING: open_files_limit needs restart. Current: $(mysql -uroot -p -e 'SHOW VARIABLES LIKE \"open_files_limit\";' -sN | awk '{print $2}')"
# 觀察 10 分鐘
sleep 600
# 恢復原值 (視情況)
# mysql -uroot -p -e "SET GLOBAL max_connections = 3000;"

七、 總結

Too many connections 不是病，是症狀。 核心動作三步走：

1. 監控定基線： 記錄 max_used_connections 日峰值，配置 max_connections = 峰值 × 1.5~2。
2. 連接池守門： 應用層嚴格限制池大小、空閒回收、洩漏檢測，杜絕「佔著茅坑不拉屎」的長連接。
3. 慢查詢清道夫： 定期 pt-query-digest 分析慢日誌，優化 Top 10 慢 SQL，釋放被堵塞的連接。

建立連接數告警規則 (threads_connected / max_connections > 80% 觸發)，配合自動擴容腳本，實現從「救火」到「防火」的轉變。