您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 資料庫相關知識

解決 MySQL "Too many connections" 錯誤：根因分析、配置調優、代碼層面修復與監控預警全方案

編輯：MySQL 資料庫相關知識

ERROR 1040: Too many connections 是 MySQL 運維中最常見的報警之一。本文從連接洩漏代碼根因、配置參數調整、架構層面連接池治理、監控預警體系四個維度，給出完整解決方案與預防指南。

錯誤現象


Can not connect to MySQL Server
Error: Too many connections
Errno: 1040

默認 max_connections = 151（5.7+），達到上限後新連線被拒。

根因一：應用代碼連接洩漏（最常見）

典型錯誤模式


// 錯誤：異常拋出時未關閉連接
Connection conn = null;
try {
    conn = dataSource.getConnection();
    Statement stmt = conn.createStatement();
    stmt.executeUpdate(sql);  // 可能拋出異常
    // 正常路徑才會執行 close()
    conn.close();
} catch (SQLException e) {
    log.error(e);
    // 忘記 conn.close()！連接洩漏
}

正確模式：try-with-resources (Java 7+)


// 自動關閉，即使拋出異常
try (Connection conn = dataSource.getConnection();
     Statement stmt = conn.createStatement()) {
    stmt.executeUpdate(sql);
}
// 編譯器自動生成 finally { close(); }

其他語言對應

Python: with conn.cursor() as cur: 或 conn.close() 在 finally
Go: defer db.Close() 或 defer rows.Close()
PHP: mysqli_close($link) 在腳本結束或 register_shutdown_function
Node.js: 連接池自動管理，注意 pool.end() 优雅關閉

根因二：連接池配置不當

參數	問題	建議
最大連接數過大	超過 MySQL `max_connections`	連接池上限 ≤ MySQL max_connections * 0.8（預留管理連接）
最小閒置連接過多	佔用資源、觸發 MySQL 空閒斷開	最小 = 核心業務並發基線，通常 10-20
連接獲取超時過長	業務堵塞、級聯故障	獲取超時 1-3s，查詢超時 5-10s
空閒回收時間過長	MySQL 端主動斷開（wait_timeout=8h），池中殘留失效連接	`testOnBorrow=true` + `validationQuery=SELECT 1`，或 `minEvictableIdleTimeMillis < wait_timeout`

根因三：長事務/慢查詢佔用連接

大事務持有連接數秒甚至數分鐘
未加索引的大表掃描、鎖等待
批次作業未分批、未異步化

解決：拆分大事務、優化慢 SQL、異步處理非即時業務。

方案一：調整 MySQL max_connections（治標）

方法 1：配置文件永久生效


# /etc/my.cnf 或 /etc/mysql/my.cnf
[mysqld]
max_connections = 1000
# 同步調大相關緩衝區
thread_cache_size = 100
open_files_limit = 65535

重啟生效：systemctl restart mysqld

方法 2：運行時動態調整（無需重啟，重啟後失效）


SET GLOBAL max_connections = 1000;

方法 3：mysqld_safe 啟動腳本修改（非 systemd 環境）


# /usr/local/mysql/bin/mysqld_safe
# 找到 max_connections 參數行修改

方案二：系統層面支撐高連接數


# /etc/security/limits.conf
mysql soft nofile 65535
mysql hard nofile 65535

# /etc/sysctl.conf
fs.file-max = 1000000
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
# sysctl -p 生效

方案三：架構層面治理（治本）

統一連接池庫：HikariCP (Java)、SQLAlchemy pool (Py)、database/sql (Go)，禁用自建池
連接獲取超時 + 查詢超時雙重保護：防止單點慢查詢拖垮整個池
只讀業務走從庫：讀寫分離分散連接壓力
ProxySQL/中間件：連接多路複用、緩衝突發連接、熔斷限流
監控告警：
- Threads_connected / max_connections > 70% 告警
- Connection_errors_max_connections > 0 立即告警
- 應用層連接池指標：active, idle, waiting, usage%

排查腳本：找出佔用連接的用戶/主機/命令


-- 當前連接分布
SELECT 
  USER, HOST, DB, COMMAND, TIME, STATE, INFO,
  COUNT(*) AS conn_count
FROM information_schema.PROCESSLIST
GROUP BY USER, HOST, DB, COMMAND
ORDER BY conn_count DESC;

-- 找出睡眠連接（疑似洩漏）
SELECT * FROM information_schema.PROCESSLIST 
WHERE COMMAND = 'Sleep' AND TIME > 60
ORDER BY TIME DESC;