このセクションでは、MySQL サーバーがクライアント接続を管理する方法について説明します。
サーバーは、複数のネットワークインタフェースでクライアント接続をリスニングできます。 接続マネージャスレッドは、サーバーがリスニングするネットワークインタフェース上のクライアント接続リクエストを処理します:
どのプラットフォームでも、1 つのマネージャースレッドが TCP/IP 接続要求を処理します。
Unix では、同じマネージャスレッドが Unix ソケットファイルの接続リクエストも処理します。
Windows では、1 つのマネージャスレッドが共有メモリ接続要求を処理し、もう 1 つのマネージャスレッドが名前付きパイプ接続要求を処理します。
すべてのプラットフォームで、追加のネットワークインタフェースを有効にして、管理 TCP/IP 接続リクエストを受け入れることができます。 このインタフェースは、「「普通」」 TCP/IP リクエストを処理するマネージャスレッド、または別のスレッドを使用できます。
サーバーは、待機していないインタフェースを処理するためのスレッドを作成しません。 たとえば、Windows サーバーで名前付きパイプ接続のサポートが有効になっていない場合、これらの接続を処理するスレッドは作成されません。
個々のサーバープラグインまたはコンポーネントは、独自の接続インタフェースを実装できます:
X プラグイン を使用すると、MySQL Server は X プロトコル を使用してクライアントと通信できます。 セクション20.5「X プラグイン」を参照してください。
接続マネージャースレッドは、各クライアント接続を、その接続の認証および要求を処理する専用スレッドに関連付けます。 マネージャースレッドは、必要に応じて新しいスレッドを作成しますが、まずスレッドキャッシュを調べて接続に使用できるスレッドが含まれているかどうかを確認することによって、それを回避することを試みます。 接続が終了すると、スレッドキャッシュが満杯でない場合は、そのスレッドがスレッドキャッシュに返されます。
この接続スレッドモデルでは、現在接続しているクライアントと同数のスレッドが存在し、多数の接続を処理するためにサーバーのワークロードを拡大する必要がある場合にはいくつか欠点があります。 たとえば、スレッドの作成と破棄の負荷が大きくなります。 また、各スレッドにスタック領域などのサーバーリソースとカーネルリソースが必要になります。 多数の同時接続に対応するには、スレッドあたりのスタックサイズは小さく保つ必要があり、それが小さくなりすぎるか、またはサーバーで大量のメモリーを消費することになる状況につながります。 ほかのリソースを使い果たす可能性もあり、スケジューリングのオーバーヘッドがかなり大きくなる可能性があります。
MySQL Enterprise Edition には、オーバーヘッドを削減してパフォーマンスを向上させるために設計された代替スレッド処理モデルを提供するスレッドプールプラグインが含まれています。 これは、多数のクライアント接続のステートメント実行スレッドを効率的に管理して、サーバーのパフォーマンスを向上させるスレッドプールを実装します。 セクション5.6.3「MySQL Enterprise Thread Pool」を参照してください。
クライアント接続を処理するスレッドをサーバーがどのように管理するかを制御し、モニターするには、いくつかのシステム変数とステータス変数が関連します。 (セクション5.1.8「サーバーシステム変数」およびセクション5.1.10「サーバーステータス変数」を参照してください。)
thread_cache_sizeシステム変数はスレッドキャッシュサイズを決定します。 デフォルトでは、サーバーは起動時に値のサイズを自動設定しますが、このデフォルトをオーバーライドするように明示的に設定できます。 値 0 を指定すると、キャッシュが無効になり、新しい接続ごとにスレッドが設定され、接続の終了時に破棄されます。Nの非アクティブな接続スレッドをキャッシュできるようにするには、サーバーの起動時または実行時にthread_cache_sizeをNに設定します。 関連付けられていたクライアント接続が終了すると、接続スレッドは非アクティブになります。キャッシュ内のスレッド数と、スレッドをキャッシュから取得できなかったために作成されたスレッド数を監視するには、
Threads_cachedおよびThreads_createdのステータス変数を確認します。スレッドスタックが小さすぎると、サーバーが処理できる SQL ステートメントの複雑さ、ストアドプロシージャの再帰深度およびその他のメモリー消費アクションが制限されます。 スレッドごとに
Nバイトのスタックサイズを設定するには、thread_stackをNに設定してサーバーを起動します。
サーバーが同時に接続できるクライアントの最大数を制御するには、サーバーの起動時または実行時に max_connections システム変数を設定します。 より多くのクライアントが同時に接続を試みる場合、サーバーが処理するように構成されているため、max_connections を増やす必要があります (セクションB.3.2.5「接続が多すぎます」 を参照)。 max_connections の制限に達したためにサーバーが接続を拒否した場合、サーバーは Connection_errors_max_connections ステータス変数を増分します。
mysqld では、実際には max_connections + 1 クライアント接続が許可されます。 追加の接続は、CONNECTION_ADMIN 権限 (または非推奨の SUPER 権限) を持つアカウントで使用するために予約されています。 通常のユーザー (必要ないユーザー) ではなく管理者に権限を付与することで、管理者はサーバーに接続し、権限のないクライアントの最大数が接続されている場合でも SHOW PROCESSLIST を使用して問題を診断できます。 セクション13.7.7.29「SHOW PROCESSLIST ステートメント」を参照してください。
MySQL 8.0.14 の時点では、専用の IP アドレスおよびポートを使用して設定できる管理ネットワークインタフェース上の管理接続もサーバーで許可されます。 セクション5.1.12.2「管理接続管理」を参照してください。
Group Replication プラグインは、内部セッションを使用して MySQL Server と対話し、SQL API 操作を実行します。 MySQL 8.0.18 へのリリースでは、これらのセッションは max_connections サーバーシステム変数で指定されたクライアント接続制限にカウントされます。 これらのリリースでは、グループレプリケーションの起動時または操作の実行試行時にサーバーが max_connections 制限に達した場合、操作は失敗し、グループレプリケーションまたはサーバー自体が停止する可能性があります。 MySQL 8.0.19 からは、グループレプリケーションの内部セッションはクライアント接続とは別に処理されるため、max_connections の制限にはカウントされず、サーバーがこの制限に達しても拒否されません。
MySQL でサポートされるクライアント接続の最大数 (つまり、max_connections を設定できる最大値) は、いくつかの要因によって異なります:
指定されたプラットフォーム上のスレッドライブラリの品質。
使用可能な RAM の量。
RAM の量は接続ごとに使用されます。
各接続のワークロード。
目的のレスポンス時間。
使用可能なファイル記述子の数。
Linux または Solaris では、使用可能な RAM が多数あり、それぞれのワークロードが少ない場合、またはレスポンス時間のターゲットが要求されない場合、少なくとも 500 から 1000 の同時接続と 10,000 の接続を定期的にサポートできる必要があります。
max_connections 値を増やすと、mysqld に必要なファイル記述子の数が増えます。 必要な数のディスクリプタが利用できない場合、サーバーは max_connections の値を削減します。 ファイル記述子の制限に関するコメントについては、セクション8.4.3.1「MySQL でのテーブルのオープンとクローズの方法」 を参照してください。
open_files_limit システム変数の増加が必要になる場合がありますが、これには、MySQL で使用できるファイル記述子の数に関するオペレーティングシステム制限の引上げが必要になることもあります。 制限値を増やすことができるかどうか、およびその実行方法については、使用するオペレーティングシステムのドキュメントを参照してください。 セクションB.3.2.16「ファイルが見つからず同様のエラーが発生しました」も参照してください。