Practical MySQL & MariaDB

MySQL パスワード変更方法（ALTER USER完全ガイド）8.0/5.7対応・rootリセット・エラー対処

ユーザーと権限
目次

1. 【結論】MySQLユーザーのパスワード変更コマンド一覧（最短回答）

MySQLでユーザーのパスワードを変更する基本コマンドは ALTER USER です。
MySQL 5.7以降ではこの方法が推奨されており、8.0でも同様に使用します。

1.1 基本形（もっとも使用頻度が高い）

ALTER USER 'username'@'localhost' IDENTIFIED BY 'newpassword';
  • username：変更対象のユーザー名
  • localhost：接続元ホスト（ユーザーは「ユーザー名＋ホスト」で識別される）
  • newpassword：新しいパスワード

実行後、即時反映されます。通常は FLUSH PRIVILEGES; は不要です（ALTER USERは自動で権限テーブルを更新します）。

つまずきやすい点

  • 同じユーザー名でも @'localhost' と @'%' は別ユーザー扱い
  • パスワード内の記号はシングルクォートで囲む必要あり

1.2 リモート接続ユーザー（%）の変更

ALTER USER 'username'@'%' IDENTIFIED BY 'newpassword';

% は「任意のホスト」を意味します。
クラウド環境や外部接続許可ユーザーでよく使用されます。

注意

  • SELECT User, Host FROM mysql.user; で事前確認すると安全
  • 想定と違うHostに変更してもログインできません

1.3 認証方式を指定して変更（8.0で重要）

MySQL 8.0ではデフォルト認証方式が caching_sha2_password です。
古いクライアントと接続できない場合は、方式を明示します。

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'newpassword';
  • mysql_native_password：旧方式（互換性重視）
  • caching_sha2_password：8.0標準方式（推奨）

よくある失敗

  • 古いPHPやクライアントが8.0標準方式に未対応
  • 認証方式を変更せずに「ログインできない」と判断してしまう

1.4 権限不足エラーが出た場合

エラー例：

ERROR 1227 (42000): Access denied; you need (at least one of) the SYSTEM_USER privilege(s)

この場合、現在ログインしているユーザーに変更権限がありません。

確認：

SHOW GRANTS FOR CURRENT_USER();

rootまたは十分な権限を持つユーザーで実行してください。

1.5 変更後の確認方法

SELECT User, Host, plugin FROM mysql.user WHERE User='username';
  • plugin列で認証方式を確認
  • 実際にログインして接続確認するのが確実

1.6 既存セッションの扱い

パスワード変更後：

  • 新規接続は新パスワード必須
  • 既存セッションは環境により即切断される場合あり
  • 本番環境では業務時間外に実施推奨

2. MySQLのユーザーとホストの基本（詰まる原因を先に潰す）

MySQLでは、ユーザーは単純な「ユーザー名」ではなく、「ユーザー名 + 接続元ホスト（Host）」の組み合わせで識別されます。
この仕組みを理解していないと、「パスワードを変更したのにログインできない」という典型的なトラブルが発生します。

2.1 ユーザーは「user@host」で1セット

例：

  • 'appuser'@'localhost'
  • 'appuser'@'%'
  • 'appuser'@'192.168.1.%'

これらは すべて別ユーザー扱い です。
そのため、localhost用のパスワードを変更しても、%用のユーザーには影響しません。

確認コマンド：

SELECT User, Host FROM mysql.user ORDER BY User, Host;

つまずきやすい点

  • 同名ユーザーが複数存在していることに気付かない
  • localhostで変更したのに、実際はTCP接続（127.0.0.1）でログインしている

2.2 localhostと127.0.0.1は別扱い

MySQLでは：

  • localhost → UNIXソケット接続（ローカル内部接続）
  • 127.0.0.1 → TCP/IP接続

環境によっては異なるユーザーがマッチします。

確認：

mysql -u username -p -h 127.0.0.1

上記でログインできない場合、@'127.0.0.1' のユーザーが存在しない可能性があります。

2.3 現在のログインユーザーを確認する

「どのユーザーでログインしているか」を把握することが重要です。

SELECT CURRENT_USER();

これは「実際に認証されたユーザー@ホスト」を表示します。

SELECT USER(); は接続要求時の情報を表示するため、必ずしも一致しません。

2.4 権限の確認（SHOW GRANTS）

パスワード変更ができない場合、権限不足が原因のことがあります。

SHOW GRANTS FOR 'username'@'host';

または現在ログイン中のユーザー：

SHOW GRANTS FOR CURRENT_USER();

最低限必要な権限

  • ALTER USER
  • または SYSTEM_USER（8.0以降）

2.5 典型的な失敗パターン

  1. Host違いで変更している
  2. 認証方式が異なる（8.0で多発）
  3. そもそも対象ユーザーが存在しない

ユーザー存在確認：

SELECT User, Host FROM mysql.user WHERE User='username';

この仕組みを理解していれば、パスワード変更関連のトラブルの大半は回避できます。

3. 推奨手順：ALTER USERで安全に変更する（MySQL 8.0/5.7共通）

MySQL 5.7以降では、ALTER USER を使用したパスワード変更が標準かつ推奨方法です。
古い UPDATE mysql.user による直接更新は、バージョンによっては動作が異なり、将来的な互換性リスクもあるため避けます。

3.1 事前チェック（変更前に必ず確認）

パスワード変更前に、次の3点を確認してください。

① 対象ユーザーとHostの確認

SELECT User, Host FROM mysql.user WHERE User='username';
  • 同名ユーザーが複数存在していないか確認
  • localhost と % を間違えない

② 現在の認証方式の確認（8.0では重要）

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';
  • caching_sha2_password（8.0標準）
  • mysql_native_password（旧方式）

認証方式が原因で接続できないケースがあります。

③ 現在のログインユーザー確認

SELECT CURRENT_USER();

権限不足エラーを避けるため、rootまたは適切な権限を持つユーザーで実行してください。

3.2 ALTER USERの実行（標準形）

ALTER USER 'username'@'localhost'
IDENTIFIED BY 'NewStrongPassword123!';

実行すると即時反映されます。
FLUSH PRIVILEGES; は通常不要です。

注意点

  • パスワードポリシー（validate_password）に違反すると ERROR 1819 が発生
  • 特殊文字を含む場合は必ずシングルクォートで囲む

3.3 認証方式を指定して変更（必要な場合のみ）

8.0環境で古いクライアントを使用している場合：

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'NewStrongPassword123!';

変更するべきケース：

  • 古いPHP / 古いMySQLクライアントで接続不可
  • caching_sha2_password 未対応環境

変更しない方が良いケース：

  • 新しい環境で問題なく接続できている場合（標準方式の方が安全）

3.4 変更後の確認

① 認証方式確認

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

② 実際にログインして確認

mysql -u username -p

ログインできるか必ずテストしてください。

3.5 既存セッションへの影響

パスワード変更後：

  • 新規接続 → 新パスワード必須
  • 既存接続 → 環境により維持される場合あり
  • 本番環境 → アプリ接続再起動が必要な場合あり

よくある失敗

  • アプリ側の接続情報を更新していない
  • 設定ファイルに古いパスワードが残っている

3.6 本番環境での安全運用ポイント

  • 業務時間外に実施
  • 事前にアプリ設定ファイル確認
  • SSH接続を切断しない状態で作業
  • root変更時は復旧手段を確保

4. MySQL 8.0と5.7の違い

MySQLのパスワード変更で問題が起きる最大の原因は、MySQL 8.0と5.7の認証方式の違いです。
特に「変更したのにログインできない」ケースの多くは、認証プラグイン（authentication plugin）の差異に起因します。

Diagram showing the difference between MySQL 5.7 mysql_native_password and MySQL 8.0 caching_sha2_password authentication methods
Authentication difference between MySQL 5.7 and MySQL 8.0

4.1 デフォルト認証方式の違い

バージョンデフォルト認証方式
MySQL 5.7mysql_native_password
MySQL 8.0caching_sha2_password

MySQL 8.0では、セキュリティ強化のため caching_sha2_password が標準になりました。
しかし、古いクライアント（古いPHP、古いMySQL Connectorなど）はこれに対応していない場合があります。

確認方法：

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

よくあるトラブル

  • 8.0で作成したユーザーに旧クライアントが接続できない
  • エラーが出ても原因が認証方式と気付かない

4.2 互換性のために認証方式を変更する方法

古い環境と接続する必要がある場合のみ、以下のように変更します。

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'NewStrongPassword123!';

変更後は必ず接続テストを実施してください。

注意

  • セキュリティ面では caching_sha2_password の方が安全
  • むやみに旧方式へ変更しないこと
  • 可能ならクライアント側を更新する方が望ましい

4.3 旧式の直接UPDATEは推奨されない

MySQL 5.7以前では次のような方法が使われていました。

UPDATE mysql.user
SET authentication_string=PASSWORD('newpassword')
WHERE User='username';
FLUSH PRIVILEGES;

しかし、この方法は：

  • バージョン依存が強い
  • 8.0では仕様変更がある
  • 将来的に非推奨

原則：ALTER USERを使用する

4.4 validate_passwordプラグインの挙動差

MySQL 5.7および8.0では、パスワードポリシー（強度チェック）機能が標準で使用可能です。

確認：

SHOW VARIABLES LIKE 'validate_password%';

ポリシーに違反すると：

ERROR 1819 (HY000)

が発生します。

8.0ではセキュリティ基準が厳しくなっている環境が多いため、
5.7からアップグレード後にパスワード変更が通らなくなるケースがあります。

4.5 バージョン確認方法

自分の環境がどのバージョンか不明な場合：

SELECT VERSION();

バージョンを確認せずに対処すると、誤った方法を適用する可能性があります。

5. rootパスワードを忘れた場合の復旧（安全重視の手順）

MySQLの root ユーザー（管理者）パスワードを忘れた場合、通常のログインはできません。
この場合は 権限テーブル（grant tables）を一時的に無効化して再設定します。ただし、この作業はセキュリティリスクを伴うため、手順を正確に実行してください。

5.1 本当にrootパスワードが必要か確認する

まず以下を確認します。

  • OS側の sudo 権限があるか
  • auth_socket 認証が有効か（Ubuntu系で多い）

確認例：

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

plugin が auth_socket の場合、OSのrootユーザーでログイン可能なことがあります。

sudo mysql

この方法で入れる場合、パスワード再設定だけで済みます。

5.2 復旧フロー（一般的な手順）

① MySQLサーバーを停止

sudo systemctl stop mysql

② 権限テーブルを無効化して起動

sudo mysqld_safe --skip-grant-tables &

--skip-grant-tables は「認証を無効化するオプション」です。
この状態では誰でも接続できるため、作業は迅速に行ってください。

③ MySQLに接続

mysql -u root

パスワード不要で接続できます。

④ rootパスワードを再設定（推奨方法）

ALTER USER 'root'@'localhost'
IDENTIFIED BY 'NewStrongPassword123!';

重要

  • 直接 UPDATE mysql.user を使用しない
  • ALTER USERを使用する（バージョン互換性のため）

⑤ 権限テーブル再有効化

FLUSH PRIVILEGES;

⑥ MySQLを通常モードで再起動

sudo systemctl restart mysql

その後、通常ログイン確認：

mysql -u root -p

5.3 よくある失敗

  • skip-grant-tablesのまま放置する（重大なセキュリティリスク）
  • rootのHostを誤って変更する
  • 認証方式を不適切に変更して接続不能になる

5.4 本番環境での注意

  • 外部公開サーバーでは必ずメンテナンス時間帯に実施
  • SSH接続を維持した状態で作業
  • 可能なら事前バックアップ

rootパスワード復旧は慎重に実施すれば安全に行えます。

6. よくあるエラーと対処（エラー文で流入を拾う）

MySQLのパスワード変更時には、いくつか典型的なエラーが発生します。
ここでは、検索されやすいエラーコード別に原因と対処法を整理します。

6.1 ERROR 1819（パスワードがポリシー要件を満たしていない）

エラー例：

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

原因

validate_password プラグインによる強度チェックに失敗しています。

現在のポリシー確認

SHOW VARIABLES LIKE 'validate_password%';

重要な設定：

  • validate_password.length
  • validate_password.policy
  • validate_password.mixed_case_count
  • validate_password.number_count
  • validate_password.special_char_count

対処法①（推奨）：強いパスワードを使用する

  • 12文字以上
  • 大文字・小文字・数字・記号を含める
  • 辞書単語を避ける

対処法②（一時的に緩和する場合）

SET GLOBAL validate_password.policy = LOW;

作業後は元の設定に戻すことを推奨します。

よくある失敗

  • 本番環境でポリシーを緩和したまま放置
  • 設定変更にSUPER権限が必要なことを見落とす

6.2 ERROR 1227（権限不足）

エラー例：

ERROR 1227 (42000): Access denied; you need (at least one of) the SYSTEM_USER privilege(s)

原因

現在のユーザーに ALTER USER または SYSTEM_USER 権限がありません。

権限確認

SHOW GRANTS FOR CURRENT_USER();

対処

rootまたは十分な権限を持つユーザーで実行します。

必要に応じて：

GRANT ALTER USER ON *.* TO 'username'@'host';
FLUSH PRIVILEGES;

注意

  • 8.0では SYSTEM_USER 権限が必要なケースあり
  • 本番環境では最小権限の原則を守る

6.3 パスワード変更後にログインできない

主な原因

  1. Host違い
  2. 認証方式の不一致
  3. クライアント未対応
  4. アプリ設定未更新

① Host確認

SELECT User, Host FROM mysql.user WHERE User='username';

② 認証方式確認

SELECT plugin FROM mysql.user WHERE User='username';

③ 認証方式変更（必要な場合）

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'NewStrongPassword123!';

④ アプリ側設定確認

  • .env
  • config.php
  • 接続文字列（DSN）

よくある失敗

  • MySQLだけ変更してアプリ側未修正
  • Docker環境でコンテナ再起動していない

6.4 パスワード変更後も古いパスワードでログインできる

通常、ALTER USER 実行後は即反映されます。

原因として考えられるもの：

  • 実際には別Hostのユーザーを変更している
  • 接続が別サーバー（レプリカ）に向いている
  • セッションキャッシュ

確認：

SELECT CURRENT_USER();

接続先とユーザーを正確に把握することが重要です。

7. セキュリティ運用：パスワードポリシーとベストプラクティス

パスワード変更は「一度設定すれば終わり」ではありません。
実務では、強度管理・権限設計・運用ルールを組み合わせてセキュリティを維持します。

7.1 validate_passwordプラグインの活用

MySQLにはパスワード強度を強制する機能があります。

現在の設定確認

SHOW VARIABLES LIKE 'validate_password%';

主な設定項目

  • validate_password.length（最低文字数）
  • validate_password.policy（LOW / MEDIUM / STRONG）
  • validate_password.mixed_case_count
  • validate_password.number_count
  • validate_password.special_char_count

設定例（最低12文字・中程度ポリシー）

SET GLOBAL validate_password.length = 12;
SET GLOBAL validate_password.policy = MEDIUM;

注意

  • GLOBAL変更は再起動でリセットされる場合あり
  • 永続化には設定ファイル（my.cnf / my.ini）で指定

7.2 強固なパスワードの最低条件

実務で推奨される基準：

  • 12文字以上
  • 大文字・小文字・数字・記号を含む
  • 辞書単語を避ける
  • 他サービスと使い回さない

例：

X9v!pQ4z#Lm2

避けるべき例

password123
mysql2025
companyname!

7.3 定期変更より重要なこと

「半年ごとの変更」よりも重要なのは、漏洩前提の設計です。

① アプリ用ユーザーを分離

  • rootをアプリで使用しない
  • 最小権限ユーザーを作成

例：

GRANT SELECT, INSERT, UPDATE ON dbname.* TO 'appuser'@'localhost';

② 権限の最小化（最小権限の原則）

必要な操作だけ許可することで、被害範囲を限定できます。

③ 監査・ログの活用

ログ確認例：

tail -f /var/log/mysql/mysql.log

MySQL Enterpriseでは監査プラグインも利用可能です。

7.4 本番環境での運用ポイント

  • 本番変更前にステージングで検証
  • 変更履歴を管理（Gitやドキュメント）
  • 変更後は必ず接続テスト
  • SSH接続を維持したまま作業

7.5 やってはいけないこと

  • rootアカウントをアプリで使用
  • パスワードをソースコードに直接記載
  • validate_passwordを無効化して放置
  • skip-grant-tables状態で放置

パスワード管理は単発作業ではなく、継続的な運用設計が重要です。

8. FAQ（よくある質問）

8.1 Q. パスワード変更後、接続中のセッションはどうなりますか？

A. 原則として、新規接続には新しいパスワードが必要になります。
既存セッションについては、環境や設定により即時切断される場合と維持される場合があります。

実務上は：

  • 本番環境では業務時間外に実施
  • アプリケーション側を再起動して接続を更新

を推奨します。

8.2 Q. パスワード変更したのにログインできません

主な原因は次の3つです。

  1. Host違い（localhost と % など）
  2. 認証方式の不一致（8.0で多発）
  3. アプリ設定未更新

確認コマンド：

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

特に plugin 列を確認してください。

8.3 Q. 特定ユーザーだけにパスワード変更を許可できますか？

可能です。

GRANT ALTER USER ON *.* TO 'username'@'host';
FLUSH PRIVILEGES;

MySQL 8.0では SYSTEM_USER 権限が必要なケースもあります。

SHOW GRANTS FOR 'username'@'host';

で権限を確認してください。

8.4 Q. MariaDBでも同じ方法ですか？

基本的に ALTER USER は使用可能ですが、

  • 認証方式
  • パスワードポリシーの仕様
  • バージョンごとの差異

があるため、環境により挙動が異なる場合があります。

確認：

SELECT VERSION();

MySQL Community Editionでは標準で履歴保持機能はありません。

8.5 Q. パスワード変更履歴は確認できますか？

対策：

  • 監査ログを有効化
  • 外部ログ管理
  • 運用ドキュメントで履歴管理

例：

tail -f /var/log/mysql/mysql.log

8.6 Q. root以外のユーザーもskip-grant-tablesで復旧できますか？

可能ですが、非常に危険な状態になります。
作業後は必ず通常モードへ戻してください。

9. まとめ

MySQLのパスワード変更は、単純なコマンド操作に見えても、ユーザーとHostの組み合わせ・認証方式・権限設計を理解していないとトラブルにつながります。

本記事で押さえるべき重要ポイントは次の通りです。

9.1 基本はALTER USERを使用する

ALTER USER 'username'@'localhost'
IDENTIFIED BY 'NewStrongPassword123!';
  • 5.7以降の標準方法
  • 直接 UPDATE mysql.user は非推奨
  • 通常は FLUSH PRIVILEGES 不要

9.2 ユーザーは「user@host」で管理される

  • localhost と % は別ユーザー
  • 同名ユーザーが複数存在する可能性あり
  • SELECT User, Host FROM mysql.user; で確認

9.3 8.0では認証方式に注意

  • 8.0標準：caching_sha2_password
  • 旧環境互換：mysql_native_password
  • 接続できない場合はpluginを確認
SELECT plugin FROM mysql.user WHERE User='username';

9.4 rootパスワード復旧は慎重に

  • --skip-grant-tables は一時的措置
  • 作業後は必ず通常モードへ戻す
  • 本番環境ではメンテナンス時間帯に実施

9.5 エラーの大半は原因が明確

  • ERROR 1819 → ポリシー違反
  • ERROR 1227 → 権限不足
  • ログイン不可 → Host違い・認証方式不一致

9.6 実務では「最小権限」と「運用設計」が重要

  • rootをアプリで使用しない
  • 専用ユーザーを作成
  • 強固なパスワードポリシーを設定
  • 変更後は必ず接続テスト

MySQLのパスワード管理は、単なる変更作業ではなく、安全なデータベース運用の基礎です。
環境に応じた適切な方法を選択し、確実に実施してください。