MySQL 資源限制實戰：帳號級配額守護穩定與安全

MySQL 支援對單個帳號施加四類資源配額：每小時最大連接數、每小時最大查詢數、每小時最大更新數、最大同時連接數。這不僅能防濫用、惡意掃描、失控腳本，還能在多租戶環境下實現公平調度。本文詳解配置語法、統計機制、重置策略、實戰場景。

一、四大限制維度與適用場景

關鍵點： 統計單位是帳號（user@host），而非客戶端 IP 或進程。同一帳號從多個客戶端連接，計數器共享；達到上限後後續操作報錯 ER_USER_LIMIT_REACHED。

二、配置語法：GRANT ... WITH ...

-- 創建帳號並施加限制
CREATE USER 'app_user'@'%' IDENTIFIED BY 'password';
GRANT SELECT, INSERT ON db.* TO 'app_user'@'%'
    WITH MAX_QUERIES_PER_HOUR 10000
         MAX_UPDATES_PER_HOUR 2000
         MAX_CONNECTIONS_PER_HOUR 500
         MAX_USER_CONNECTIONS 20;

-- 僅修改現有帳號限制（不改權限）
GRANT USAGE ON *.* TO 'app_user'@'%'
    WITH MAX_QUERIES_PER_HOUR 20000;

WITH 子句可組合使用，0 表示無限制（預設）。

三、避坑指南：權限與限制要匹配

• 只讀帳號別設更新配額： 無 INSERT/UPDATE/DELETE 權限的帳號設 MAX_UPDATES_PER_HOUR 無意義，純屬配置噪音。
• 全局生效，無法針對具體 DB/表： 限制是帳號級全局的，無法做到「僅限制對核心表的寫入頻率」。
• 統計周期為滾動 1 小時： 非自然小時（00:00-01:00），而是「最近 3600 秒」。

四、計數器重置：測試後必清零，重啟自動歸零

-- 全局重置所有帳號計數器（需 RELOAD 權限）
FLUSH USER_RESOURCES;

-- 單帳號重置（需 GRANT 權限）
GRANT USAGE ON *.* TO 'app_user'@'%';  -- 不帶 WITH 子句即重置為 0

注意： MAX_USER_CONNECTIONS（同時連接數）不受計數器重置影響，它是實時檢查當前活躍連接數。服務器重啟會清零所有計數器。

五、實戰場景：OA 系統防掛馬、防刷單

某 B/S 架構 OA 系統，正常用戶登入後長連接，小時連接數≈1。配置：

GRANT USAGE ON *.* TO 'oa_user'@'%'
    WITH MAX_CONNECTIONS_PER_HOUR 10
         MAX_USER_CONNECTIONS 3;

效果：

• 木馬/掃描腳本嘗試高頻建連 → 觸發 MAX_CONNECTIONS_PER_HOUR 封禁。
• 單用戶多標籤/多設備 → MAX_USER_CONNECTIONS=3 允許合理併發，超過即拒絕。
• 正常業務完全無感，異常流量精準攔截。

六、監控與告警

-- 查看帳號當前使用情況
SHOW STATUS LIKE 'Conn_%';  -- 全局連接統計
-- 無直接命令查看單帳號實時計數，需從 information_schema.processlist 統計或監控工具采集

建議接入 Prometheus + Grafana，采集 mysql_global_status_threads_connected、mysql_user_resource_limits 等指標，設置「使用率 > 80%」告警。

總結

帳號資源限制是低成本、高效果、零代碼侵入的保護層。核心三步：按最小權限原則授權 → 按業務基線配額 → 監覽計數器趨勢。配合 MAX_USER_CONNECTIONS 實時限流、FLUSH USER_RESOURCES 運維重置，構建「事前限額、事中熔斷、事後審計」閉環。