rootパスワードの通常変更と、管理接続が使えない場合の復旧は別の作業です。まず対象のUser/Host・認証方式と既存の管理経路を確認します。認証無効化、DB再初期化、ユーザー表の直接更新を通常の変更手順にはしません。

通常変更と緊急復旧を選び分ける

状況	先に確認すること
既存の管理接続がある	対象アカウント/権限/認証方式と依存先を確認。通常のアカウント管理文で計画する
ソケット認証を使っている	許可されたOSユーザーと接続経路を確認。パスワード未設定と決めつけて認証方式を変えない
管理資格情報を失った	運用担当と管理サービスの回復手段を確認。認証を外す起動は承認と接続隔離を伴う別作業
変更後も接続不可	接続先/User/Host/ドライバ/TLS/新しい秘密値の反映先を照合。DBを再初期化しない

変更前に対象アカウントを読み取り確認する

次はMySQL 8.0で、既に許可された管理接続がある場合の読み取り例です。認証に失敗した接続からは実行できません。接続先とCURRENT_USER()、rootのHost/認証方式/ロック/期限を照合します。アカウント情報をそのまま公開せず、authentication_stringやパスワードを出力しません。

SELECT VERSION() AS server_version, CURRENT_USER() AS authenticated_account;

-- Authorized administrator only. Do not publish account information.
SELECT User, Host, plugin, account_locked, password_expired, password_lifetime
FROM mysql.user
WHERE User = 'root'
ORDER BY Host;

接続できることと必要な管理権限があることは別です。管理者用とアプリ実行用を分け、情報確認のためにGRANT ALLや外部接続範囲の拡大を行わないでください。

復旧後に終えるべき確認

1. 通常起動へ戻り、認証回避オプションが残っていないことを実効設定で確認する。
2. 新規接続で新しい資格情報が有効、古い資格情報が拒否されることを確認する。既存接続の継続だけで合格にしない。
3. 既存データ・必要なアプリ処理・権限/認証方式が意図どおりか比較する。
4. 依存アプリ/秘密情報保管先を調整し、復旧用ファイルや出力に秘密値が残っていないか、組織の保管/失効手順で扱う。記事を理由に本番ファイルを無断削除しない。

一次資料: MySQL 8.0の公式復旧手順、8.4の公式復旧手順、ALTER USERの対象と要件、現在も有効なSET PASSWORD構文、mysql_native_passwordの状態、検証コンポーネントの導入条件。

この記事の要点

MySQL 5.7+ / 8.0 標準: ALTER USER 'root'@'localhost' IDENTIFIED BY 'newpass' 外部コマンド: mysqladmin -u root -p password 'newpass'（旧来） パスワード忘れ時: 正規の管理経路を先に確認し、必要なら承認済みの版別復旧計画へ。user表の直接更新は行わない MySQL 8.0 の caching_sha2_password: 利用ドライバ/TLSを確認する。古いクライアントのための旧認証への差し戻しを初手にしない パスワードポリシー: 実効ポリシーと導入方式を確認。1819を消すために緩和/削除しない

方法 1: ALTER USER（MySQL 5.7.6+ / 8.0 標準）

下は資格情報/認証方式を変更する旧例です。対象版・アカウント・依存アプリへの影響を確認し、公開例のパスワードは使用しません。mysql_native_passwordへの差し戻しを互換性対策としてコピーせず、通常のALTER USER後にFLUSH PRIVILEGESは不要です:

-- 通常: 現パスワード入力で接続済の状態で
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewSecret123!';

-- 認証プラグインも指定（MySQL 8.0 互換性問題対策）
ALTER USER 'root'@'localhost'
    IDENTIFIED WITH mysql_native_password BY 'NewSecret123!';

-- 反映
FLUSH PRIVILEGES;

-- 確認
SELECT User, Host, plugin FROM mysql.user WHERE User = 'root';

方法 2: mysqladmin password（旧来）

下はmysqladminの旧例です。秘密値を引数へ書くと履歴やプロセス情報に残るおそれがあります。公開例を使わず、対話入力や運用上の安全な更新方式を選びます。変更後は新規接続を別に検証します:

# 対話入力
mysqladmin -u root -p password
# Enter password: ← 旧パスワード
# New password: ← 新パスワード
# Confirm new password:

# 引数で渡す（履歴に残るので非推奨）
mysqladmin -u root -p'OldPass' password 'NewSecret123!'

方法 3: SET PASSWORDと対象版を確認する

SET PASSWORD自体はMySQL 8.0でも有効です。下の旧コメントは文全体が非推奨という意味ではありません。PASSWORD()関数を使う旧構文は8.0へ流用せず、公式の対象版構文と認証方式を照合してください。

-- MySQL 5.7.5 以前
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('NewSecret123!');

-- MySQL 5.7.6 以降は ALTER USER 推奨。古い構文は非推奨警告
SET PASSWORD FOR 'root'@'localhost' = 'NewSecret123!';

方法 4: パスワードを忘れた場合の復旧

以下は過去の復旧例で、順番にコピーして実行する手順ではありません。 認証を無効化する方式はローカル接続者にも全権限を与え得ます。通常変更や原因未確認のAccess deniedには使いません。公式のinit-file方式を含む版別手順、停止影響・バックアップ・実行OSユーザー・接続隔離・通常復帰の確認を伴う、承認済み管理者の別作業です。user表の直接UPDATEは行いません。

手順 1: MySQL を停止

下のサービス名は配置例で、MySQL/MariaDBを全行停止しません。対象インスタンス・データ領域・保守時間・起動管理方式を確認し、所有するサービスの正常停止を使います。psの文字列一致だけで停止対象を決めないでください。

sudo systemctl stop mysql       # Ubuntu/Debian
sudo systemctl stop mysqld      # RHEL/CentOS
sudo systemctl stop mariadb     # MariaDB

# プロセス残存確認
ps aux | grep mysqld

手順 2: 権限チェックなしで起動

下は認証防御を外す旧起動例です。 systemdのMYSQLD_OPTSが実際に使われるかは配布物次第で、全環境の手順ではありません。既存DBと二重起動せず、DB専用OSユーザー/所有権・実ソケット・ローカル利用者の制限も確認します。skip-networkingだけでローカル接続まで安全になるわけではありません。

# 安全のためネットワーク接続も無効化
sudo mysqld_safe --skip-grant-tables --skip-networking &

# または直接（systemd 環境）
sudo systemctl set-environment MYSQLD_OPTS="--skip-grant-tables --skip-networking"
sudo systemctl start mysql

手順 3: パスワード変更

下のUPDATE mysql.userとPASSWORD()をMySQL 8.0の復旧に使用しません。 シェルのmysql、SQL、EXIT後の断片も混在しているので一括実行不可です。公式のskip-grant方式ではFLUSH PRIVILEGESでアカウント管理文を有効にしてからALTER USERを使いますが、これは通常変更後にFLUSHが必要という意味ではありません。

-- 認証なしで接続
$ mysql -u root

-- MySQL 5.7+ : ALTER USER は --skip-grant-tables 状態だと動かない
-- 一旦 FLUSH PRIVILEGES してから

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewSecret123!';
FLUSH PRIVILEGES;
EXIT;

-- 5.6 以前 / 直接更新（最終手段）
UPDATE mysql.user
SET authentication_string = PASSWORD('NewSecret123!')
WHERE User = 'root' AND Host = 'localhost';
FLUSH PRIVILEGES;

手順 4: 通常起動に戻す

次のkillall mysqldを使用しないでください。 名前に一致した別インスタンスまで停止し得ます。復旧用オプションを環境変数から外すだけでは稼働中プロセスの設定は変わりません。対象を正常停止し、正規の設定で起動して認証有効・新しい資格情報・既存データ/アプリ接続を確認する別段階です。

# mysqld_safe で起動したプロセスを止める
sudo killall mysqld
# または
sudo systemctl unset-environment MYSQLD_OPTS

# 通常起動
sudo systemctl start mysql

# 新パスワードで接続確認
mysql -u root -p

MySQL 8.0 の認証プラグイン問題

以下のmysql_native_passwordへのALTERとdefault_authentication_plugin設定は旧例です。mysql_native_passwordは8.0.34で非推奨、8.4で既定無効、9.0で削除されています。サーバー全体を旧方式へ戻さず、実際のドライバ/対応認証/TLSを先に確認します。

MySQL 8.0 は既定の認証プラグインが caching_sha2_password に変わり、古い PHP / MySQL クライアントから接続できないことがあります:

SQLSTATE[HY000] [2054] The server requested authentication method
unknown to the client

-- 旧プラグインに戻す
ALTER USER 'root'@'localhost'
    IDENTIFIED WITH mysql_native_password BY 'NewSecret123!';

-- 全ユーザー確認
SELECT User, Host, plugin FROM mysql.user;

次のmy.cnf変更も通常の解決策として実行しません。対象版で存在する設定か、既存/将来のアカウントと起動に与える影響を調べる必要があります:

[mysqld]
default_authentication_plugin = mysql_native_password

パスワードポリシー（validate_password）

検証機能の導入状態は配布元/版/移行履歴で異なります。以下のLOW変更やUNINSTALLは防御を弱める旧例で実行しません。現在の実効ポリシーへ適合する新しい秘密値を用意します:

ERROR 1819 (HY000): Your password does not satisfy the current
policy requirements

-- 現在のポリシー確認
SHOW VARIABLES LIKE 'validate_password%';

-- 主な設定
-- validate_password.policy        LOW / MEDIUM / STRONG
-- validate_password.length        8 (既定)
-- validate_password.mixed_case_count  1
-- validate_password.number_count      1
-- validate_password.special_char_count 1

-- 一時的に緩める（再起動で戻る）
SET GLOBAL validate_password.policy = LOW;
SET GLOBAL validate_password.length = 8;

-- 完全に無効化（非推奨）
UNINSTALL PLUGIN validate_password;

MySQL 8.0 の component_validate_password

MySQL 8.0でも導入経路によりコンポーネント/旧プラグイン/未導入が異なります。下は状態参照と導入/削除が混在する旧例です。確認のためにUNINSTALL/INSTALLを行いません:

-- 状態確認
SELECT * FROM mysql.component;
SHOW VARIABLES LIKE 'validate_password%';

-- アンインストール
UNINSTALL COMPONENT 'file://component_validate_password';

-- 再インストール
INSTALL COMPONENT 'file://component_validate_password';

Bitnami / Docker 環境での root pw

環境	確認方法
Bitnami	対象の配布物の公式手順と秘密情報保管先を確認。ファイルの存在や内容を一律に保証しない
Docker official mysql	初期化時の設定と既存DBを区別。現在の環境変数は変更後の実パスワードの証明ではない
MAMP	対象配布版と変更履歴で確認。固定の既定値で安全と扱わない
XAMPP	対象配布版と変更履歴で確認。空パスワードを推奨しない
AWS RDS	管理サービスの公式操作と対象アカウント/依存先を確認。自己管理DBの復旧起動を流用しない

FAQ

Q: ALTER USER で「Operation ALTER USER failed」
A: 固有番号・SQLSTATE・対象User/Host・必要権限・認証方式を確認します。1396/1819/1290等を一括で同じ原因にせず、存在しないアカウント、ポリシー、復旧モード等を分けて調べます。

Q: root@localhost と root@% は別物？
A: 別アカウントです。実際に認証へ使われる行と利用先を確認し、原因未確認で両方を変更したり、%を新設したりしません。

Q: 安全な root pw の生成
A: openssl rand -base64 24 や pwgen -s 24 1 でランダム生成、パスワードマネージャに保存。

関連手順を選ぶ

初期資格情報の確認、ALTER USERの属性と影響から目的に合うものを選べます。エラーはMySQLエラー一覧の子ページから選んでください。