MySQL 普通用戶本地登入失效：匿名用戶遮蔽機制深度解析與解決方案

MySQL 普通用戶本地登入失效：匿名用戶遮蔽機制深度解析與解決方案

經典場景：建立帳號 'user'@'%' 遠程連線正常，但本機 mysql -u user -p 卻報 Access denied for user 'user'@'localhost'，甚至免密登入卻無權限。 本文從 MySQL 認證排序規則切入，徹底解析「匿名用戶遮蔽」根因，提供兩種標準解法與驗證方法。

1. 現象重現

# Root 建立帳號
mysql> GRANT ALL ON prod.* TO 'rose'@'%' IDENTIFIED BY 'rose';

# 本地登入失敗
[root@mysrv ~]# mysql -u rose -prose
ERROR 1045 (28000): Access denied for user 'rose'@'localhost' (using password: YES)

# 免密登入卻進入（實際走匿名用戶）
[root@mysrv ~]# mysql -u rose -p
Enter password:  # 直接 Enter
Welcome to the MySQL monitor...
mysql> USE prod;
ERROR 1044 (42000): Access denied for user ''@'localhost' to database 'prod'

# 遠程登入正常
C:\> mysql -h 192.168.8.240 -u rose -prose  # 成功

2. 根因：MySQL 認證排序規則

MySQL 讀取 mysql.user 表到記憶體，依以下規則排序，取第一個匹配的行進行驗證：

1. Host 欄位匹配精確度優先：'localhost' > '127.0.0.1' > '%'。
2. User 欄位非空優先：'rose' > ''（匿名）。

本案例匹配行

結果：本地連線實際使用 ''@'localhost' 驗證（無密碼），故免密可進，但無任何權限。

3. 為何 Root 不受影響？

mysql_install_db 同時建立 'root'@'localhost'。本地登入時，'root'@'localhost' 與 ''@'localhost' Host 同精確度，但 User 非空優先，故 Root 走正確帳號驗證。

4. 兩種標準解法

解法一：補授權精確 Host（推薦，保留匿名用戶相容性）

mysql> GRANT ALL ON prod.* TO 'rose'@'localhost' IDENTIFIED BY 'rose';
FLUSH PRIVILEGES;

新增 'rose'@'localhost' 後，Host 精確度並列，User 非空優先，本地登入即走正確帳號。

解法二：刪除匿名用戶（最徹底，兼顧安全審計）

mysql> DROP USER ''@'localhost';
mysql> FLUSH PRIVILEGES;

移除遮蔽源頭，所有本地連線強制匹配具名帳號。

5. 驗證登入實際使用帳號

mysql> SELECT USER(), CURRENT_USER();
+----------------+----------------+
| USER()         | CURRENT_USER() |
+----------------+----------------+
| rose@localhost | rose@localhost |  -- 解法生效後
+----------------+----------------+

• USER()：客戶端嘗試的帳號（含主機）
• CURRENT_USER()：Server 實際用於驗證的帳號（權限表匹配行）

兩者一致即表示無遮蔽問題。

6. 最佳實務檢查清單

1. 建立帳號時同時授權 'user'@'%' 與 'user'@'localhost'。
2. 初始化資料庫後立即刪除匿名用戶：DELETE FROM mysql.user WHERE User=''; FLUSH PRIVILEGES;
3. 定期審計 mysql.user 確認無殘留匿名帳號。
4. 連線失敗時優先用 SELECT USER(), CURRENT_USER() 定位實際驗證帳號。

理解「Host 精確度 > User 非空」的認證排序邏輯，是解決 MySQL 連線詭異問題的金鑰。