MySQLの「Access denied for user」エラーの原因と解決方法｜1045・1698・1044

MySQLやMariaDBに接続しようとして「Access denied for user」と表示されるのは、サーバーが接続またはその操作を許可しなかったときです。原因はパスワードの誤りだけではなく、接続元のホストがアカウントと合っていない、認証方式が違う、データベースへの権限がない、といった場合にも同じ文言が出ます。この記事では、エラー文から原因を絞り込み、アカウントを直す手順を説明します。MySQL 8.0・8.4とMariaDB 10.6以降を前提にしています（2026年10月時点）。

エラー番号で原因を分ける

なお、ERROR 2002（ソケットに接続できない）や ERROR 2003（Can't connect to MySQL server）は、サーバーに届いていないエラーで、Access deniedとは原因が別です。サーバーが動いているか、ホスト名・ポート・ファイアウォールを確認してください。

エラー文のユーザーとホストを読む

Access deniedのエラー文には、サーバーから見た接続者が 'ユーザー名'@'ホスト' の形で出ます。MySQLのアカウントは、ユーザー名と接続元ホストの組で1つです。'wpuser'@'localhost' と 'wpuser'@'%' は別のアカウントで、パスワードや権限も別々に持ちます。

管理者でログインし、そのユーザー名のアカウントがどのホストで登録されているかを確認します。

SELECT user, host, plugin FROM mysql.user WHERE user = 'wpuser';

ログインできた場合は、実際にどのアカウントとして認証されたかを CURRENT_USER() で確認できます。USER() は接続しようとした名前、CURRENT_USER() はサーバーが当てはめたアカウントです。

SELECT USER(), CURRENT_USER();
SHOW GRANTS;

匿名ユーザーに当たっている場合

ユーザー名が空の匿名ユーザー（''@'localhost'）が残っていると、'wpuser'@'%' で作ったつもりのアカウントで同じサーバーから接続したときに、ホストの指定がより具体的な匿名ユーザーのほうが選ばれ、パスワードが合わずに拒否されることがあります。匿名ユーザーがあるかを確認し、不要なら削除します。

SELECT user, host FROM mysql.user WHERE user = '';
DROP USER ''@'localhost';

mysql_secure_installation を実行すると、匿名ユーザーの削除も対話的に行えます。

パスワードと権限を直す

管理者でログインしてから作業します。UbuntuやDebianでは、OSの管理者権限で sudo mysql と実行するとrootでログインできます（次の節を参照）。

パスワードを設定し直す場合は、ALTER USER を使います。アカウントを削除して作り直す必要はありません。

ALTER USER 'wpuser'@'localhost' IDENTIFIED BY '新しいパスワード';

接続元に合うアカウントが無い場合は作成し、必要なデータベースにだけ権限を与えます。*.* への ALL PRIVILEGES や WITH GRANT OPTION は、そのユーザーをサーバー全体の管理者にしてしまうので、アプリ用のユーザーには付けません。

CREATE USER 'wpuser'@'localhost' IDENTIFIED BY '新しいパスワード';
GRANT ALL PRIVILEGES ON wpdb.* TO 'wpuser'@'localhost';
SHOW GRANTS FOR 'wpuser'@'localhost';

CREATE USER、ALTER USER、GRANT による変更はすぐに反映されるので、FLUSH PRIVILEGES は不要です（mysql.user などの表を UPDATE で直接書き換えた場合にだけ必要です）。

Ubuntu・Debianのrootでログインできない（ERROR 1698）

UbuntuやDebianのパッケージで入れたMySQLでは、root@localhost が auth_socket（MariaDBでは unix_socket）で認証されるように設定されています。この方式ではパスワードを使わず、OSのrootユーザーとして接続したときだけログインできます。そのため、一般ユーザーで mysql -u root -p と実行すると、正しいパスワードを入れても1698で拒否されます。

sudo mysql

rootの認証方式は変えずに、アプリや作業用には別のユーザーを作るのが安全です。phpMyAdminなど、パスワードでrootとしてログインしたいツールがある場合も、rootを変えるより管理用のユーザーを別に作ることを検討してください。

rootのパスワードがわからない場合

sudo mysql でもログインできない環境では、公式マニュアルの「How to Reset the Root Password」の手順で再設定します。権限の確認を一時的に止めて起動し、パスワードを設定し直す方法の概要は次のとおりです。権限の確認が止まっている間は誰でも接続できるので、--skip-networking でネットワークからの接続を止め、作業が終わったらすぐ通常の起動に戻します。

# サービス名はディストリビューションにより mysql / mysqld / mariadb
sudo systemctl stop mysqld
sudo mysqld --user=mysql --skip-grant-tables --skip-networking &
mysql -u root

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY '新しいパスワード';
EXIT;

mysqladmin -u root -p shutdown
sudo systemctl start mysqld

--skip-grant-tables で起動した直後は ALTER USER が使えないため、先に FLUSH PRIVILEGES で権限表を読み込みます。

MySQL 8.4以降の認証方式（ERROR 1524）

MySQL 8.0では caching_sha2_password が既定の認証方式になり、古い mysql_native_password は8.0.34で非推奨、MySQL 8.4では既定で無効、MySQL 9.0で削除されました。MySQL 8.0から8.4に上げたあとに、mysql_native_password で作ったアカウントが接続できなくなった場合は、認証方式を変更します。

SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';
ALTER USER 'wpuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY '新しいパスワード';

PHPはPHP 7.4以降で caching_sha2_password に対応しています。MySQL 8.4の [mysqld] に mysql_native_password=ON と書くと古い方式を一時的に有効にできますが、MySQL 9.0では使えない設定なので、移行までのつなぎにとどめてください。MariaDBでは mysql_native_password を引き続き使えるので、このエラーはMySQL 8.4以降で起きるものです。

クライアント側の設定を疑う

コマンドで指定していないユーザー名やパスワードが、設定ファイルから読み込まれていることがあります。~/.my.cnf や /etc/mysql/my.cnf の [client] や [mysql] に、古いパスワードが書かれていないかを確認します。

# mysql コマンドが設定ファイルから読み込むオプションを表示する
mysql --print-defaults

# 設定ファイルを読まずに接続して比べる（--no-defaults は最初に書く）
mysql --no-defaults -u wpuser -p -h localhost wpdb

--print-defaults の出力にはパスワードも表示されるので、画面共有中やログに残る場所では実行しないでください。パスワードを書いた ~/.my.cnf は、chmod 600 で自分だけが読めるようにします。

WordPressでデータベースに接続できない場合

WordPressはデータベースへの接続に失敗すると「Error establishing a database connection」（日本語の環境では、これを訳したデータベース接続のエラー）を表示します。wp-config.php の接続情報と同じ値で、サーバー上から mysql コマンドで接続できるかを試すと、原因がMySQL側かWordPress側かを分けられます。

<?php
// wp-config.php の該当箇所（値は例）
define( 'DB_NAME', 'wpdb' );
define( 'DB_USER', 'wpuser' );
define( 'DB_PASSWORD', 'パスワード' );
define( 'DB_HOST', 'localhost' );

mysql -u wpuser -p -h localhost wpdb

• mysql では接続できるのにWordPressで失敗する場合は、wp-config.php の値の打ち間違い、前後の空白、パスワードに含まれる ' や \ のエスケープ漏れ（' は \' と書く）を確認します
• DB_HOST を localhost にするとソケット、127.0.0.1 にするとTCPで接続します。エラー文のホストが変わるので、アカウントのホストと合わせます
• レンタルサーバーでは、データベースのホスト名が localhost ではなく専用のホスト名になっていることがあります。サーバー会社の管理画面に表示される値を使います

まとめ

• エラー番号で切り分ける。1045はパスワードかホスト、1698は認証方式、1044は権限、1524はMySQL 8.4の認証プラグイン
• エラー文の 'ユーザー'@'ホスト' と、mysql.user に登録されたホストが合っているかを確認する
• パスワードは ALTER USER で直し、権限は必要なデータベースにだけ GRANT する。FLUSH PRIVILEGES は通常不要
• Ubuntu・Debianのrootは sudo mysql でログインする
• 設定ファイル（~/.my.cnf、wp-config.php）に古い値が残っていないかも確認する

関連記事:

• MySQLのユーザーと権限の管理
• mysql_secure_installationの使い方
• WordPressのデータベース接続エラーの対処法