# Aurora MySQL チューニングの基本的な概念
Aurora MySQL データベースを調整する前に、待機イベントとスレッドの状態はどうなっているか、またその発生理由を確認してください。InnoDB ストレージエンジンを使用するときは、Aurora MySQL の基本的なメモリとディスクアーキテクチャも確認してください。便利なアーキテクチャ図表については、「[MySQL リファレンスマニュアル](https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html)」を参照してください。
**Topics**
+ [Aurora MySQL の待機イベント](#AuroraMySQL.Managing.Tuning.concepts.waits)
+ [Aurora MySQL スレッド状態](#AuroraMySQL.Managing.Tuning.concepts.thread-states)
+ [Aurora MySQL メモリ](#AuroraMySQL.Managing.Tuning.concepts.memory)
+ [Aurora MySQL プロセス](#AuroraMySQL.Managing.Tuning.concepts.processes)
## Aurora MySQL の待機イベント
*待機イベント*はセッションが待っているリソースを示します。例えば、待機イベント `io/socket/sql/client_connection` はスレッドが新しい接続を処理中であることを示します。セッションが待機する一般的なリソースには、次のものがあります。
+ バッファへのシングルスレッドアクセス (例えば、セッションがバッファを変更しようとした場合など)
+ 別のセッションによって現在ロックされている行
+ 読み込まれたデータファイル
+ ログファイルの書き込み
例えば、クエリを満たすために、セッションで完全なテーブルスキャンを実行することがあります。データがまだメモリ上にない場合、セッションはディスク I/O が完了するまで待機します。バッファがメモリに読み込まれるときは、他のセッションが同じバッファにアクセスしているため、セッションは待機しなければならないことがあります。データベースは、事前定義された待機イベントを使用して待機を記録します。これらのイベントはカテゴリに分類されます。
待機イベント自体では、パフォーマンスの問題は表示されません。例えば、要求されたデータがメモリ上にない場合は、ディスクからデータを読み出す必要があります。あるセッションが更新のために行をロックすると、別のセッションはその行を更新できるようにロック解除されるまで待機します。コミットは、ログファイルへの書き込みが完了するまで待機する必要があります。待機は、データベースが正常に機能するために不可欠です。
一般的に、大量の待機イベントはパフォーマンスの問題を示します。そのような場合、待機イベントデータを使用して、セッションが時間を費やしている場所を特定できます。例えば、通常は分単位で実行されるレポートが数時間実行される場合、合計待機時間に最も多く寄与する待機イベントを特定できます。上位の待機イベントの原因を特定できる場合は、パフォーマンス向上のための変更を実行できることがあります。例えば、別のセッションによってロックされている行でセッションが待っている場合、ロックセッションを終了します。
## Aurora MySQL スレッド状態
*一般的なスレッド状態*は`State`一般的なクエリ処理に関連付けられている値です。例えばスレッドの状態 `sending data` は、スレッドがクエリの行を読み取り、フィルタリングして正しい結果セットを判断していることを示します。
スレッド状態を使用すると、待機イベントの使用方法と同じような仕様で Aurora MySQL を調整できます。例えば`sending data` の頻繁な発生は通常、クエリがインデックスを使用していないことを示します。スレッド状態の詳細については、*MySQL リファレンスマニュアル*の[一般的なスレッドステート](https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html)を参照してください。
Performance Insights を使用する場合、以下の条件のいずれかに当てはまります。
+ パフォーマンススキーマがオンになっている — Aurora MySQL はスレッド状態ではなく待機イベントを表示します。
+ パフォーマンススキーマがオンになっていない — Aurora MySQL はスレッド状態を表示します。
パフォーマンススキーマは、自動管理に設定することをお勧めします。パフォーマンススキーマは、潜在的なパフォーマンスの問題を調査するための追加のインサイトと優れたツールを提供します。詳細については、[Aurora MySQL における Performance Insights のPerformance Schema の概要](USER_PerfInsights.EnableMySQL.md) を参照してください。
## Aurora MySQL メモリ
Aurora MySQL では、最も重要なメモリ領域はバッファプールとログバッファです。
**Topics**
+ [バッファプール](#AuroraMySQL.Managing.Tuning.concepts.memory.buffer-pool)
### バッファプール
*バッファプール*は Aurora MySQL がテーブルとインデックスデータをキャッシュする共有メモリ領域です。クエリはディスクから読み取ることなく、頻繁に使用されるデータにメモリから直接アクセスできます。
バッファプールは、ページのリンクリストとして構成されています。*ページ*は複数の行を保持できます。Aurora MySQL は、プールからページをエージングアウトするために、最近最も使用されていない (LRU) アルゴリズムを使用します。
詳細については、*MySQL リファレンスマニュアル*の「[Buffer Pool](https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html)」(バッファプール) を参照してください。
## Aurora MySQL プロセス
Aurora MySQL は Aurora PostgreSQL とは大きく異なるプロセスモデルを使用しています。
**Topics**
+ [MySQLサーバー (mysqld)](#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld)
+ [スレッド](#AuroraMySQL.Managing.Tuning.concepts.processes.threads)
+ [スレッドプール](#AuroraMySQL.Managing.Tuning.concepts.processes.pool)
### MySQLサーバー (mysqld)
MySQL サーバーは mysqld という名前の単一のオペレーティングシステムプロセスです。MySQL サーバーは追加のプロセスを生成しません。したがって Aurora MySQL データベースは、 mysqld を使用してほとんどの作業を実行します。
MySQL サーバーが起動すると、MySQL クライアントからのネットワーク接続をリッスンします。クライアントがデータベースに接続すると、mysqld はスレッドを開きます。
### スレッド
接続マネージャースレッドは、各クライアント接続を専用スレッドに関連付けます。このスレッドは、認証を管理し、ステートメントを実行し、結果をクライアントに返します。接続マネージャは、必要に応じて新しいスレッドを作成します。
*スレッドキャッシュ*は使用可能なスレッドのセットです。接続が終了すると、キャッシュがいっぱいでない場合、MySQL はスレッドをスレッドキャッシュに返します。`thread_cache_size` システム可変は、スレッドキャッシュのサイズを決定します。
### スレッドプール
*スレッドプール*は複数のスレッドグループで構成されています。各グループは一連のクライアント接続を管理します。クライアントがデータベースに接続すると、スレッドプールはラウンドロビン方式でスレッドグループに接続を割り当てます。スレッドプールは接続とスレッドを分離します。接続と、それらの接続から受信した文を実行するスレッドの間には、固定された関係はありません。