MySQL 採用基於「用戶+主機」雙維度的權限模型,通過 mysql 系統庫中的授權表實現精細化訪問控制。本文深度解析權限生效的四種場景、授權表結構、root 用戶安全加固、匿名用戶風險、密碼管理最佳實踐,幫助構建安全合規的數據庫訪問體系。
| 場景 | 觸發條件 | 生效時機 | 影響範圍 |
|---|---|---|---|
| 服務器啟動 | mysqld 進程啟動 | 啟動過程中 | 全局:讀取所有授權表入內存 |
| 語句修改 | GRANT/REVOKE/SET PASSWORD | **立即生效** | 內存授權表即時更新 |
| 直接修改授權表 | INSERT/UPDATE/DELETE mysql.* 表 | 需執行 FLUSH PRIVILEGES 或 mysqladmin flush-privileges | 重新載入授權表到內存 |
| 重啟服務 | 重啟 mysqld | 重啟完成 | 同場景 1 |
USE db_name 生效⚠️ 密碼修改不會踢掉已連接會話,需配合 KILL CONNECTION 強制斷開。
| 表名 | 權限層級 | 核心列 |
|---|---|---|
user | 全局 | Host, User, Password, Select_priv, Insert_priv, ..., Super_priv, ... |
db | 數據庫級 | Host, Db, User, Select_priv, Insert_priv, ... |
tables_priv | 表級 | Host, Db, User, Table_name, Table_priv, Column_priv |
columns_priv | 列級 | Host, Db, User, Table_name, Column_name, Column_priv |
procs_priv | 存儲例程級 | Host, Db, User, Routine_name, Routine_type, Proc_priv |
proxies_priv | 代理用戶 | Host, User, Proxied_host, Proxied_user, With_grant |
| 誤區 | 正確做法 |
|---|---|
以為 GRANT 後需 FLUSH PRIVILEGES | GRANT/REVOKE/SET PASSWORD 立即生效,無需 FLUSH |
| 直接 UPDATE mysql.user 修改密碼不 FLUSH | 直接修改授權表**必須** FLUSH PRIVILEGES 或重啟 |
| 密碼修改後舊連接自動斷開 | 舊連接持續有效,需 KILL CONNECTION 強制斷開 |
以為 host=% 包含 localhost | % 不匹配 localhost (Unix socket),需單獨授權 user@localhost |
授予 ALL PRIVILEGES 給應用賬戶 | 嚴禁,最小權限原則 |
MySQL 權限系統雖成熟但細節多、陷阱深。核心原則:**僅 root 管授權表、安裝即清理匿名/設強密碼/限制 root 遠程、最小權限授予、定期審計、善用 8.0 角色/動態權限/密碼策略**。將安全基線固化為自動化腳本(Ansible/Terraform/Shell),納入 CI/CD 流水線,構建「不可變基礎設施」下的數據庫安全防線。