MySQL のインストール後、mysql_install_db スクリプトを実行して権限テーブルを初期設定していなければ、これを行う。 See 項4.4.4. 「MySQL 権限の初期設定」。 以下のコマンドを実行して初期権限をテストする。

shell> mysql -u root test

エラーが発生することなく接続できるはずである。また、MySQL データベースディレクトリに user.MYD ファイルがあることを確認する。 通常、これは PATH/var/mysql/user.MYD である。ここで PATH は、MySQL インストール先ディレクトリのパス名である。

初期インストール後、サーバに接続してユーザとそのアクセス権をセットアップする。

shell> mysql -u root mysql

MySQL root ユーザには、最初パスワードがないため、問題なく接続できるはずである。これはセキュリティ上のリスクでもあるため、他の MySQL ユーザをセットアップするとき、同時に root パスワードも設定すべきである。

root として接続しようとして以下のエラーが表示された場合

Access denied for user: '@unknown' to database mysql

これは、user テーブルの User カラムに 'root' 値がなく、mysqld がクライアントのホスト名を解決できないことを意味する。この場合、--skip-grant-tables オプションでサーバを再起動し、/etc/hosts ファイルまたは \windows\hosts ファイルを編集してホストのエントリを追加する必要がある。

以下のエラーが発生した場合

shell> mysqladmin -u root -pxxxx ver
Access denied for user: 'root@localhost' (Using password: YES)

入力したパスワードが正しくないことを意味する。 See 項4.4.8. 「パスワードの設定」。

root のパスワードを忘れた場合、--skip-grant-tables オプションで mysqld を再起動してパスワードを変更できる。 See 項A.4.2. 「忘れたルートパスワードをリセットする方法」。

パスワードを指定していないにもかかわらず上記のエラーが発生する場合、何らかの my.cnf ファイルに正しくないパスワードが存在していることを意味する。See 項4.1.2. 「my.cnf オプション設定ファイル」。 以下のように --no-defaults オプションを使用すると、オプション設定ファイルの使用を避けることができる。

shell> mysqladmin --no-defaults -u root ver

既存の MySQL インストールを、バージョン 3.22.11 より前からバージョン 3.22.11 以降にアップグレードした後で、mysql_fix_privilege_tables スクリプトを実行していなければ、これを実行する。GRANT ステートメントが導入された MySQL バージョン 3.22.11 では、権限テーブルの構造が変更されている。 See 項2.5.6. 「権限テーブルのアップグレード」。

セッション途中で権限が変更されているようであれば、スーパーユーザが変更した可能性がある。権限テーブルを再読み込みすると、新しいクライアント接続に影響し、また、項4.4.3. 「権限の変更はいつ反映されるか」 で説明されているように、既存の接続にも影響する。

パスワードが機能しない場合に INSERT、UPDATE、または SET PASSWORD ステートメントを使用してパスワードを設定する際には PASSWORD() 関数を使用することが必要である。GRANT ... IDENTIFIED BY ステートメントまたは mysqladmin password コマンドを使用してパスワードを指定する場合には、PASSWORD() 関数は不要である。 See 項4.4.8. 「パスワードの設定」。

localhost は、ユーザのローカルホスト名のシノニムである。また、ホストを明示的に指定せずにクライアントが接続しようとした場合のデフォルトホストでもある。ただし、MIT-pthread を使用するバージョン 3.23.27 より前の MySQL を使用している場合、localhost への接続は行われない（localhost 接続は Unix ソケットを使用して行われるが、これは当時の MIT-pthread にはサポートされていなかった）。このようなシステムでこの問題を回避するには、--host オプションを使用してサーバホストを明示的に指定する。これにより、mysqld サーバへの TCP/IP 接続が行われる。この場合、サーバホストの user テーブルエントリに実際のホスト名があることが必要である（これは、サーバと同じホスト上でクライアントプログラムを実行している場合も同様である）。

mysql -u user_name db_name でデータベースに接続しようとして Access denied エラーが発生する場合、user テーブルに問題がある可能性がある。mysql -u root mysql を実行し、以下の SQL ステートメントを実行して、これをチェックする。

mysql> SELECT * FROM user;

この結果に、使用コンピュータのホスト名および MySQL ユーザ名とマッチする Host カラムおよび User カラムのエントリが含まれていなければならない。

Access denied エラーメッセージには、ログインしようとしているユーザ名、接続元のホスト、およびパスワードを使用したかどうかが示される。通常、エラーメッセージで表示されたホスト名とユーザ名に完全にマッチするエントリが 1 つ、user テーブルに存在していなければならない。Using password: NO を含むエラーメッセージが表示された場合、パスワードなしでログインしようとしたことを意味する。

MySQL サーバを実行しているホスト以外のホストから接続しようとして以下のエラーが発生する場合、そのホストと一致するレコードが user テーブルにないということである。

Host ... is not allowed to connect to this MySQL server

これを解決するには、コマンドラインツール mysql をサーバホスト上で使用して、user、db、または host テーブルに、接続しようとしているユーザとホスト名の組み合わせのレコードを追加し、mysqladmin flush-privileges を実行する。 実行している MySQL がバージョン 3.22 ではなく、接続しようとしているコンピュータの IP アドレスまたはホスト名がわからない場合、user テーブルの Host カラムに '%' を設定し、サーバマシン上で --log オプションを使用して mysqld を再起動する。クライアントマシンから接続を試行すると、MySQL ログの情報により、実際の接続がどのように行われたかわかる。次に、user テーブルエントリの '%' の値を、ログで表示された実際のホスト名に置き換える。そうしないと、システムのセキュリティを保てない。

Linux 上でこの問題が発生した場合、考えられる他の原因としては、使用している glibc とは違うバージョンの glibc でコンパイルされたバイナリ MySQL バージョンを使用していることが挙げられる。この場合、OS/glibc をアップグレードするか、ソース MySQL バージョンをダウンロードして自分でコンパイルする。ソース RPM は通常、コンパイルおよびインストールが簡単なので、これは大きな問題ではない。

ホスト名で接続しようとしたにもかかわらず、エラーメッセージにホスト名が表示されない、またはホスト名が IP で表示される場合

shell> mysqladmin -u root -pxxxx -h some-hostname ver
Access denied for user: 'root@' (Using password: YES)

これは、IP からホスト名に逆引きしようとしたときに MySQL でエラーが発生したことを意味する。この場合、mysqladmin flush-hosts を実行して内部 DNS キャッシュをリセットすることができる。 See 項5.5.5. 「MySQL の DNS の使用」。

恒久的な解決方法

mysql -u root test は正常終了するのに mysql -h your_hostname -u root test では Access denied となる場合、user テーブルに正しいホスト名がない可能性がある。 通常、このような場合、user テーブルエントリの Host 値が完全修飾されていないホスト名を指定し、システムの名前解決ルーチンが完全修飾されたドメイン名を返している（またはその逆）。 たとえば、user テーブルにホスト 'tcx' のエントリがあるが、DNS に MySQL にホスト名として 'tcx.subnet.se' を指示した場合、これは機能しない。この場合、Host カラム値としてホストの IP アドレスを持つ user テーブルエントリを追加してみる。または、Host 値として 'tcx.%' などのワイルドカードを含む user テーブルエントリを追加することもできる。ただし、‘%’ で終わるホスト名の使用は、安全ではないので、推奨できない。

mysql -u user_name test は正常終了するのに、mysql -u user_name other_db_name ではエラーが発生する場合、db テーブルに other_db_name のエントリがない。

サーバマシンでは mysql -u user_name db_name が動作するのに、別のクライアントマシンでは mysql -h host_name -u user_name db_name が動作しない場合、user テーブルまたは db テーブルにクライアントマシンが登録されていない。

Access denied の原因がわからない場合は、user テーブルから Host 値にワイルドカードが含まれているエントリ（‘%’ または ‘_’ を含むエントリ）をすべて削除する。 よくある間違いは、Host='%' および User='some user' の新規エントリを挿入し、これで、同一マシンから接続する際には localhost を指定できると考えていることである。これがうまくいかない理由は、デフォルト権限として、Host='localhost' および User='' のエントリが含まれているためである。Host 値が 'localhost' の場合、'%' よりも具体的なため、localhost からの接続時に新しいエントリよりもデフォルト権限が優先される。正しい指定の方法は、Host='localhost' および User='some_user' の 2 つ目のエントリを挿入するか、Host='localhost' および User='' のエントリを削除することである。

以下のエラーが発生した場合、db テーブルまたは host テーブルに問題がある可能性がある。

Access to database denied

db テーブルの Host カラムに空白値がある場合、その db テーブルエントリに対してホストを指定するエントリが 1 つ以上、host テーブルに存在していることを確認する。

SQL コマンド SELECT ...INTO OUTFILE または LOAD DATA INFILE 使用時にエラーが発生する場合、user テーブルの該当エントリで FILE 権限が有効化されていないと考えられる。

クライアントプログラムは、オプション設定ファイルまたは環境変数で指定された接続パラメータを使用する。See 付録 F. 環境変数。 コマンドラインで接続パラメータを指定しなかったときに、クライアントが間違ったデフォルトの接続パラメータを送っているようであれば、ホームディレクトリの .my.cnf ファイルおよび環境変数を確認する。システムレベルの MySQL オプション設定ファイルも確認できるが、ここでクライアント接続パラメータが指定されている可能性は低い。See 項4.1.2. 「my.cnf オプション設定ファイル」。 クライアントをオプションなしで実行して Access denied が発生する場合、オプション設定ファイルに古いパスワードが指定されていないか確認する。 See 項4.1.2. 「my.cnf オプション設定ファイル」。

権限テーブルを（INSERT または UPDATE ステートメントを使用して）直接変更した場合、その変更は無視されたように見えることがある。サーバに権限テーブルを再読み込みさせるには、FLUSH PRIVILEGES ステートメントを発行するか mysqladmin flush-privileges コマンドを実行する必要がある。このことを行わない場合、変更は次回のサーバ再起動時まで有効とならない。UPDATE コマンドで root パスワードを設定しても、権限をフラッシュするまでは、パスワードが変更されたことをサーバがまだ認識しないため、そのパスワードを指定する必要はない。

Perl、PHP、Ruby、Python、または ODBC プログラムでアクセスに問題があった場合、mysql -u user_name db_name または mysql -u user_name -pyour_pass db_name を使用して接続してみる。mysql クライアントを使用して接続できる場合、問題はプログラムにあり、アクセス権限にはない。 注意: -p とパスワードの間にスペースは入れない。また、--password=your_pass 構文を使用してパスワードを指定することもできる。-p オプションだけを使用した場合、パスワードが要求される。

テスト用に、--skip-grant-tables オプションで mysqld デーモンを開始する。次に MySQL 権限テーブルを変更し、変更によって意図した結果が得られているかどうか mysqlaccess スクリプトを使用してチェックできる。変更が意図したとおりであれば、mysqladmin flush-privileges を実行し、新しい権限テーブルを使用して起動するように mysqld サーバに指示する。注意: 権限テーブルを再読み込みすると、--skip-grant-tables オプションが無効になる。これにより、サーバをシャットダウンして再起動することなく、権限テーブルの使用を始めることができる。

上記のいずれでもうまくいかない場合は、デバッグオプション（--debug=d,general,query など）で mysqld デーモンを開始する。試された接続に関するホスト情報、ユーザ情報、および発行された各コマンドに関する情報が出力される。 See 項E.1.2. 「トレースファイルの作成」。

MySQL 権限テーブルに関するその他の問題が発生し、その旨メーリングリストに投稿する場合は、MySQL 権限テーブルのダンプも必ず提供すること。mysqldump mysql コマンドを使用すれば権限テーブルをダンプできる。問題を投稿するときは、必ず mysqlbug スクリプトを使用すること。See 項1.7.1.3. 「バグまたは問題を報告する方法」。 mysqldump を実行する際、--skip-grant-tables で mysqld を再起動することが必要な場合もある。