liuziyi

改數據庫密碼時，你是否總在“安全”和“業務連續性”之間糾結？傳統單密碼模式下，一旦執行密碼修改，現有連接會瞬間失效，應用直接報連接錯誤；若等業務低峰期改，又會錯過安全整改窗口。而 MySQL 8.0（8.0.14 及以上版本）推出的雙密碼機制，完美解決了這個痛點——支持主密碼、輔助密碼并存，改密碼時無需中斷現有連接，輕松實現“無縫切換”。

一、先搞懂：雙密碼機制是什么？

雙密碼機制允許一個 MySQL 賬戶同時擁有兩個有效密碼：

• 主密碼：新設置的密碼，用于后續應用程序的長期連接；
• 輔助密碼：舊密碼的臨時保留形式，用于兼容未完成密碼更新的現有連接或應用。

簡單說，改密碼時先讓“新舊密碼同時生效”，等所有應用都切換到新密碼后，再徹底禁用舊密碼。整個過程中，現有業務連接不會中斷，實現“零停機”密碼更新。

二、核心操作：雙密碼的“切換兩步走”

雙密碼機制的實操非常簡單，僅需兩個核心 SQL 命令，就能完成從“新舊密碼共存”到“僅新密碼生效”的切換。每個步驟都附帶效果驗證，確保操作無誤。

1. 第一步：添加新密碼，保留舊密碼（新舊共存）

當需要修改密碼時，先執行 ALTER USER 語句，用 RETAIN CURRENT PASSWORD 子句保留舊密碼作為輔助密碼，新密碼設為主密碼。

示例操作（以 root@% 賬戶為例，原密碼 123456，新密碼 123123）：

-- 新密碼（123123）設為主密碼，舊密碼（123456）保留為輔助密碼
ALTER USER 'root'@'%' IDENTIFIED BY '123123' RETAIN CURRENT PASSWORD;

操作后效果：

• 現有使用舊密碼（123456）的連接不會斷開，業務正常運行；
• 新發起的連接，無論是用主密碼（123123）還是輔助密碼（123456），都能正常登錄；
• 主密碼優先級更高，后續若需再次改密碼，默認基于主密碼更新。

2. 第二步：廢棄舊密碼，僅保留新密碼（完成切換）

等所有應用程序都已更新配置、使用新密碼（123123）連接后，再執行 DISCARD OLD PASSWORD 子句，徹底禁用輔助密碼（舊密碼）。

示例操作：

-- 丟棄輔助密碼（123456），僅主密碼（123123）生效
ALTER USER 'root'@'%' DISCARD OLD PASSWORD;

操作后效果：

• 舊密碼（123456）徹底失效，新發起的連接用舊密碼會報“訪問被拒絕”；
• 所有連接均需使用主密碼（123123），密碼更新流程完成，且全程未中斷業務。

三、關鍵細節：避免踩坑的注意事項

雙密碼機制雖簡單，但在實際使用中，有幾個細節需要特別注意，否則可能導致密碼失效或權限問題。

1. 關于“空密碼”的限制

• 若新密碼設為空（不推薦），即使加了 RETAIN CURRENT PASSWORD，輔助密碼也會被清空；
• 若賬戶當前主密碼為空，執行 RETAIN CURRENT PASSWORD 會直接失敗，必須先設置非空主密碼。

2. 更改認證插件的影響

若執行 ALTER USER 時同時修改了賬戶的身份驗證插件（如從 mysql_native_password 改為 caching_sha2_password），輔助密碼會被自動丟棄；此時若強行加 RETAIN CURRENT PASSWORD，語句會報錯。

3. 輔助密碼的“覆蓋規則”

每次執行 ALTER USER ... RETAIN CURRENT PASSWORD 時，新保留的輔助密碼會覆蓋原有的輔助密碼。例如：

1. 第一次改密碼：主密碼 A，輔助密碼（舊）B；
2. 第二次改密碼（未丟棄 B）：主密碼 C，輔助密碼（舊）A；
   此時，原輔助密碼 B 會失效，僅 C（主）和 A（輔助）有效。

四、復雜場景落地：多服務器/復制架構如何用？

在實際生產環境中，MySQL 常涉及多實例、主從復制或集群架構，此時雙密碼機制的“零停機”優勢更明顯。以“主從復制+多應用連接”場景為例，操作流程如下：

1. 第一步：更新所有主庫（非副本）的密碼
   對每臺主庫執行 ALTER USER 'ceshi'@'%' IDENTIFIED BY '新密碼' RETAIN CURRENT PASSWORD;，保留舊密碼作為輔助密碼。

2. 第二步：等待密碼修改同步到所有副本
   確保主庫的密碼更改通過二進制日志同步到所有從庫，避免從庫因密碼不匹配導致復制中斷。

3. 第三步：更新應用程序的密碼配置
   分批次修改所有使用該賬戶的應用，將數據庫連接密碼從舊密碼改為新密碼。此過程中，未更新的應用仍可通過輔助密碼（舊）連接，業務不受影響。

4. 第四步：廢棄所有服務器的輔助密碼
   待所有應用更新完成后，在每臺主庫執行 ALTER USER 'ceshi'@'%' DISCARD OLD PASSWORD;，并等待該操作同步到所有副本。

5. 驗證：所有服務器僅新密碼生效，舊密碼無法登錄，整個過程無任何業務停機。

五、權限控制：誰能操作雙密碼？

不同的雙密碼操作，需要不同的權限，避免越權修改導致安全風險。具體權限要求如下：

注意：盡量避免給普通用戶 CREATE USER 權限，若需讓其管理自己的雙密碼，授予 APPLICATION_PASSWORD_ADMIN 即可，遵循“最小權限原則”。

六、客觀看待：雙密碼機制的優勢與局限

優勢：

1. 徹底解決“改密碼停機”痛點：新舊密碼共存期間，現有連接不中斷，應用切換無感知；
2. 適配復雜架構：在主從復制、多實例集群中，可通過“先同步密碼、再更應用”的流程，避免復制中斷；
3. 安全合規：支持定期改密碼，滿足安全審計要求，同時不影響業務連續性。

局限：

• 應用層仍需適配：雙密碼機制僅解決數據庫層面的無縫切換，部分應用（如硬編碼密碼、需重啟生效的配置）仍需修改打包，可能產生輕微業務影響；
• 僅支持 MySQL 8.0.14+：低版本 MySQL 無法使用，需先升級版本（若業務允許）。

總結：雙密碼機制的最佳實踐

MySQL 8.0 雙密碼機制，本質是通過“臨時保留舊密碼”的方式，為密碼更新提供了“緩沖期”。在實際使用中，建議遵循以下流程：

1. 規劃切換窗口：選擇業務低峰期啟動操作，但無需停機；
2. 先改數據庫，再更應用：確保數據庫層面先支持雙密碼，再分批次更新應用；
3. 及時廢棄舊密碼：應用全部更新后，盡快執行 DISCARD OLD PASSWORD，避免舊密碼泄露風險；
4. 權限最小化：僅給必要賬戶授予雙密碼操作權限，減少安全隱患。

對于需要定期改密碼、又怕影響業務的團隊來說，雙密碼機制是兼顧“安全”與“可用性”的最優解，值得在 MySQL 8.0 環境中全面推廣。

。