您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 綜合教學

MySQL 連接數優化：Too many connections 根因排查與 max_connections 科學設置

編輯：MySQL 綜合教學

故障現場


ERROR 1040 (HY000): Too many connections

兩大根因

業務訪問量真高**：QPS 突增、慢查詢堆積、連接池配置不當、應用未正確關閉連接
max_configured 過小**：默認 151 (5.7+) / 100 (舊版本)，遠低於現代硬件承載能力

診斷儀表盤：三個關鍵指標


-- 1. 服務器配置上限
SHOW VARIABLES LIKE 'max_connections';
-- max_connections: 151

-- 2. 歷史峰值併發 (自啟動以來)
SHOW GLOBAL STATUS LIKE 'Max_used_connections';
-- Max_used_connections: 44

-- 3. 當前併發
SHOW GLOBAL STATUS LIKE 'Threads_connected';
-- Threads_connected: 12

科學設置公式

理想佔比：Max_used_connections / max_connections ≥ 10% (健康)、≥ 85% (預警)、= 100% (故障)


# 當前佔比
44 / 151 ≈ 29%  -- 健康區間

# 設置建議值
max_connections = Max_used_connections * 4  -- 留 4 倍餘量
-- 或
max_connections = (預估峰值 QPS × 平均事務耗時秒) + 安全餘量

動態調整 (無需重啟)


SET GLOBAL max_connections = 500;
SHOW VARIABLES LIKE 'max_connections';
-- 即時生效

持久化配置


# /etc/my.cnf
[mysqld]
max_connections = 500
# 伴隨參數 (防止文件句柄/內存不足)
open_files_limit = 65535
table_open_cache = 4000

高併發架構級優化 (單靠調大 max_connections 治標不治本)

方案	原理	適用場景
讀寫分離	主庫寫、從庫讀，分散連接壓力	讀多寫少 (90%+ 讀)
連接池優化	應用層複用連接，減少建連/斷連開銷，控制併發上限	所有 Java/Go/Python/Node 應用
線程池	Percona/MySQL Enterprise Thread Pool，用戶線程 → 工作線程組，避免線程上下文切換風暴	高併發短事務 (OLTP)
ProxySQL	連接多路復用、查詢路由、熔斷、限流、緩存	微服務、多租戶、治理需求強
拆分實例/分庫分表	物理隔離，單實例連接數自然下降	超大規模、多業務線

連接池配置黃金法則 (以 HikariCP 為例)


# 核心公式
maximumPoolSize = (CPU核心數 * 2) + 有效磁盤數
# 典型 8核 SSD: (8*2) + 1 = 17 → 設置 20-30

# 關鍵參數
minimumIdle = maximumPoolSize * 0.5  -- 保持熱連接
connectionTimeout = 30000            -- 獲取連接超時 30s
idleTimeout = 600000                 -- 空閒回收 10min
maxLifetime = 1800000                -- 最大壽命 30min (< wait_timeout)
leakDetectionThreshold = 60000       -- 洩漏檢測 1min
validationTimeout = 5000             -- 驗證查詢超時 5s