ユーザが MySQL サーバに接続しようとした場合、そのユーザ ID、およびそれを正しいパスワードで裏付けできるかどうかによって、サーバは接続の許可または拒否を行います。パスワードが正しくない場合、サーバはアクセスを完全に拒否します。正しければ、サーバは接続を許可し、段階 2 に進んで要求を待ちます。

ユーザ ID は、2 つの情報に基づきます。

ID チェックには、user テーブルの 3 つのスコープフィールド（Host、User、Password）が使用されます。user テーブルエントリが、指定されたホスト名とユーザ名に一致し、入力したパスワードが正しかった場合のみ、接続が許可されます。

user テーブルのスコープフィールドには次の方法で値を指定できます。

空白ではない Password 値は、暗号化パスワードを表します。 MySQL では、パスワードを平文テキストでは保存しません。接続しようとするユーザが入力したパスワードは、暗号化されます（PASSWORD() 関数を使用）。クライアントおよびサーバがパスワードの確認を行う際、その暗号化されたパスワードが使用されます（このとき、その接続を使って、暗号化されたパスワードが転送されることはありません）。注意: MySQL から見ると暗号化されたパスワードが実際のパスワードなので、暗号化パスワードにだれにもアクセスできないようにしてください。特に、一般のユーザに mysql データベース内のテーブルの読み取りアクセス権を与えないでください。 バージョン 4.1 より、MySQL は従来とは異なるパスワードおよびログインメカニズムを採用しており、TCP/IP パケットが盗み見されたり、mysql データベースがキャプチャされた場合でも安全になっています。

以下の例は、user テーブルエントリの Host 値および User 値のさまざまな組み合わせがどのように着信の接続に適用されるかを示したものです。

Host フィールドでは IP のワイルドカード値を使用できるので（たとえば、'144.155.166.%' で、サブネットのすべてのホストに一致）、ホストを 144.155.166.somewhere.com などと名付けてこの機能が悪用される可能性があります。これを防ぐため、MySQL は数値やドットで始まるホスト名を認めません。したがって、1.2.foo.com などのホスト名は、権限テーブルの Host カラムと決して一致しません。IP アドレスのみ IP ワイルドカード値との突き合わせが可能です。

ある接続が、user テーブルの複数のエントリと一致することがあります。たとえば、thomas.loc.gov からの fred による接続は、上記の表のいくつかのエントリと一致します。複数のエントリが一致した場合、サーバは次のようにエントリを選択します。起動時に user テーブルを読み込んだ後、それをソートします。ユーザが接続しようとしたとき、そのソート順でエントリとの突き合わせを行います。そして最初に一致したエントリを使用します。

user テーブルのソートは以下のように行われます。user テーブルが以下の内容であるとします。

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-

サーバがテーブルを読み込むと、最も具体的な Host 値を最初にもってきます（Host カラムの '%' は ``任意のホスト'' を意味し、具体性が低いとなります）。同じ Host 値のエントリ間で、最も具体的な User 値を最初にもってきます（空白の User 値は ``任意のユーザ'' を意味し、具体性が低いとなります）。ソートされた user テーブルは以下のようになります。

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-

接続が試みられると、サーバはソートされたエントリで突き合わせを行い、最初に一致したものを使用します。localhost からの jeffrey による接続に対しては、Host カラムが 'localhost' のエントリが最初に一致します。これらのうち、空白ユーザ名のエントリが接続ホスト名とユーザ名の両方で一致します（'%'/'jeffrey' エントリも一致しますが、これはテーブル内での最初の突き合わせにはなりません）。

もう 1 つ例を示します。user テーブルが以下の内容であるとします。

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-

ソートされたテーブルは以下のようになります。

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

thomas.loc.gov からの jeffrey による接続は最初のエントリと一致し、whitehouse.gov からの jeffrey による接続は 2 番目のエントリと一致します。

サーバが接続の突き合わせを行うとき、指定されたユーザ名を明示的に示すすべてのエントリが最初に使用されると誤解しがちです。これは間違っています。上記の例でもわかるように、thomas.loc.gov からの jeffrey による接続は、'jeffrey' が User フィールド値であるエントリではなく、ユーザ名なしのエントリと最初に一致します。

サーバへの接続がうまくいかない場合、user テーブルを出力して、最初の突き合わせがどれか確認してください。 正常に接続が行われても、権限が予期したものと違う場合、CURRENT_USER() 関数（バージョン 4.0.6 で導入）を使用して、その接続に実際に一致しているユーザとホストの組み合わせを確認できます。 See 項6.3.6.2. 「その他の各種関数」。