ユーザーがMySQLサーバーに接続しようとすると,サーバーはユーザーのIDと正しいパスワードを指定することでユーザーが自分のIDを検証できるかどうかに基づいて,接続を受け入れるか拒否します。できない場合，サ，バ，はアクセスを完全に拒否します。それ以外の場合，サ，バ，は接続を受け入れてステ，ジ2に進み，リクエストを待機します。

ユザのidは2の部分の情報に基づきます。

Idチェックは，用户テブルの3のスコプカラム(宿主、用户、密码)を使用して実施されます。サ，バ，は，一部の用户テ，ブル行の宿主および用户カラムがクライアントホスト名およびユーザー名と一致し,その行に指定されているパスワードがクライアントから提供された場合のみ,接続を受け入れます。許容可能な宿主および用户値にいてのルルは，セクション6.2.3“アカウント名の指定”にあります。

用户カラム値がブランクでない場合，入接続のユ，ザ，名は正確に一致する必要があります。用户値がブランクの場合，これはすべてのユ，ザ，名と一致します。入接続と一致する用户テーブル行のユーザー名がブランクである場合,ユーザーはクライアントが実際に指定した名前を持つユーザーでなく,名前のない匿名ユーザーとみなされます。つまり,接続期間中の(つまりステージ2での)今後のすべてのアクセスチェックでブランクのユーザー名が使用されることを意味します。

密码カラムはブランクにできます。これはワルドカドではなく，あらゆるパスワドが一致するという意味ではありません。これは，ユ，ザ，はパスワ，ドを指定せずに接続しなければならないことを意味します。サ，バ，がプラグインを使用してクライアントを認証する場合、プラグインが実装する認証方式で、密码カラムのパスワ，ドが使用される場合もそうでない場合もあります。この場合，MySQLサバへの認証を行う際に，外部パスワドも使用される可能性があります。

用户テ，ブル内のブランクでない密码値は暗号化パスワ，ドを表します。MySQLは，すべてのユ，ザ，が表示できるプレ，ンテキスト形式のパスワ，ドを格納しません。代わりに，接続しようとしたユ，ザ，が入力したパスワ，ドは(密码()関数を使用して)暗号化されます。そのあと,暗号化パスワードは,接続プロセス中にパスワードが正しいかどうかをチェックするときに使用されます。これは，暗号化パスワ，ドが接続を介してやりとりされずに実行されます。セクション6.3.1 "ユ，ザ，名とパスワ，ド"を参照してください。

MySQLから見ると，暗号化パスワ，ドが実際のパスワードであるため,暗号化パスワードへのアクセス権限をすべてのユーザーに付与しないようにしてください。特に，管理者以外のユ，ザ，に，mysqlデ，タベ，ス内のテ，ブルへの読み取りアクセス権限を付与しないでください。

次の表では，用户テ，ブルエントリの宿主値および用户値のさまざまな組み合わせが入接続にどのように適用されるかを示しています。

入接続のクラアントホスト名およびユザ名が用户テ，ブルの複数行と一致することもあります。このことは前の一連の例で示されており，示されている複数のエントリが，弗雷德によるthomas.loc.govからの接続に一致します。

複数の一致が可能な場合，サ，バ，はいずれを使用するかを決定する必要があります。この問題は，次のように解決されます。

サ，バ，は，具体性がもっとも高い宿主値が先になるように行を並べるソ，トル，ルを使用します。リテラルのホスト名およびIP地址アドレスは具体性がもっとも高くなります。（リテラルの IP アドレスの具体性は IP アドレスがネットマスクを持つかどうかによって影響されないため、192.168.1.13と192.168.1.0/255.255.255.0の具体性は同等とみなされます.)パタ.ン“%”は「任意のホスト」を意味するため，具体性はもっとも低くなります。空の文字列”も「任意のホスト」を意味しますが，“%”のあとにソ，トされます。同じ宿主値を持行は，もっとも具体的な用户値が最初になるよう並べられます(ブランクの用户値は「任意のユザ」を意味し，具体性がもっとも低くなります)。宿主および用户値の具体性が等しい行にいては，順序は不確定です。

用户テ，ブルが次の内容であると仮定して，これがどのように作用するかを説明します。

+-----------+----------+- |主机|用户|…+-----------+----------+- | % | root |…杰弗里，|…| localhost | root |…| localhost | |…+-----------+----------+-

サーバーがテーブルをメモリーに読み取るとき,サーバーは前に記載したルールを使用して行をソートします。ソ，ト後の結果は次のようになります。

+-----------+----------+- |主机|用户|…+-----------+----------+- | 本地主机根| |……| localhost | |…杰弗里，|…| % | root |…+-----------+----------+-

クライアントが接続しようとすると,サーバーはソート済みの行を参照し,見つかった最初の一致を使用します。杰弗里による本地主机からの接続の場合，テ，ブルの2の行が一致し，宿主および用户値が“localhost”および”であるものと，値が“%”および“杰弗里。”であるものが一致します。ソ，ト順では“localhost”行が最初になるため，サ，バ，はこの行を使用します。

次に別の例を示します。用户テ，ブルが次のようになっていると仮定します。

+----------------+----------+- | 主机用户| |…+----------------+----------+- | % | jeffrey |…| thomas.loc.gov | |…+----------------+----------+-

ソ，ト済みテ，ブルは次のようになります。

+----------------+----------+- | 主机用户| |…+----------------+----------+- | thomas.loc.gov | |…杰弗里，|…+----------------+----------+-

杰弗里によるthomas.loc.govからの接続は最初の行に一致しますが，杰弗里による任意のホストからの接続は2番目の行に一致します。

サーバーに接続できても権限が期待したものとは異なる場合,おそらくほかのアカウントとして認証されています。サバがユザの認識に使用したアカウントを見けるには，CURRENT_USER ()関数を使用します。（セクション12.14“情報関数”を参照してください.)これは，一致する用户テ，ブル行の用户および宿主値を示す，user_name@host_name形式の値を返します。たとえば，杰弗里が接続して，次のクエリ，を発行したとします。

mysql> SELECT当前用户()+----------------+ | CURRENT_USER () | +----------------+ | @ 本地主机  | +----------------+

ここで表示された結果は，一致した用户テ，ブル行の用户カラム値がブランクであることを示しています。つまり,サーバーは杰弗里を匿名ユ，ザ，として扱っています。

認証の問題を診断するための別の方法は，用户テ，ブルを出力し，テ，ブルを手作業でソ，トして，最初の一致が行われた行を確認する方法です。