wait、stage、statement、および transaction イベントの場合、パフォーマンススキーマは現在のイベントをモニターおよび格納できます。 また、イベントが終了すると、パフォーマンススキーマはそれらを履歴テーブルに格納できます。 イベントタイプごとに、パフォーマンススキーマは現在のイベントと履歴イベントの格納に 3 つのテーブルを使用します。 テーブルには次の形式の名前があります。ここで、xxx はイベントタイプ (waits, stages, statements, transactions) を示します:
events_: 「現在のイベント」テーブルには、各スレッド (スレッドごとに 1 行) の現在の監視対象イベントが格納されます。xxx_currentevents_: 「最近の履歴」テーブルには、スレッドごとに終了した最新のイベントが格納されます (スレッド当たりの最大行数まで)。xxx_historyevents_: 「長い履歴」テーブルには、グローバルに終了した最新のイベントが格納されます (すべてのスレッドで、テーブル当たりの最大行数まで)。xxx_history_long
各イベントタイプの_current テーブルにはスレッドごとに 1 つの行が含まれるため、その最大サイズを構成するためのシステム変数はありません。 パフォーマンススキーマは、個々の履歴テーブルを説明するセクションに示されているように、テーブル固有のシステム変数を使用して、サーバーの起動時に履歴テーブルのサイズを自動設定するか、サイズを明示的に構成できます。 一般的な自動サイズ設定された値は、_history テーブルではスレッドごとに 10 行、_history_long テーブルでは合計 10,000 行です。
イベントタイプごとに、_current、_history および_history_long の各テーブルに同じカラムがあります。 _current テーブルと_history テーブルのインデックス付けは同じです。 _history_long テーブルにインデックス付けがありません。
_current テーブルには、サーバー内で現在何が起こっているかが表示されます。 現在のイベントが終了すると、その_current テーブルから削除されます。
_history および_history_long のテーブルには、最近行われたことが表示されます。 履歴テーブルがいっぱいになると、新しいイベントが追加されると古いイベントは破棄されます。 テーブルの目的が異なるため、_history テーブルと_history_long テーブルの行は様々な方法で期限切れになります:
_historyは、グローバルサーバーの負荷に関係なく、個々のスレッドを調査することを目的としています。_history_longは、各スレッドではなくグローバルにサーバーを調査することを目的としています。
2 つのタイプの履歴テーブルの違いは、データ保存ポリシーに関連します。 イベントが最初に表示されたときに、両方のテーブルに同じデータが含まれています。 ただし、各テーブル内のデータは時間の経過とともに異なる期限が切れるため、各テーブルでデータが長期間または短時間保持される可能性があります:
_historyでは、テーブルに特定のスレッドの最大行数が含まれている場合、そのスレッドの新しい行が追加されると、最も古いスレッド行は破棄されます。_history_longでは、テーブルがいっぱいになると、いずれかの行を生成したスレッドに関係なく、新しい行が追加されたときに最も古い行が破棄されます。
スレッドが終了すると、そのすべての行は_history テーブルから破棄されますが、_history_long テーブルからは破棄されません。
次の例は、2 つのタイプの履歴テーブルに対してイベントを追加および破棄する方法の違いを示しています。 原則はすべてのイベントタイプに均等に適用されます。 この例は、次の前提に基づいています:
パフォーマンススキーマは、スレッドあたり 10 行を
_historyテーブルに保持し、合計 10,000 行を_history_longテーブルに保持するように構成されています。-
スレッド A は 1 秒当たり 1 つのイベントを生成します。
スレッド B は 100 イベント/秒を生成します。
他のスレッドは実行されていません。
5 秒後:
A および B は、それぞれ 5 および 500 のイベントを生成しました。
_historyには、A に 5 行、B に 10 行が含まれています。 スレッド当たりの記憶域は 10 行に制限されているため、A の行は破棄されていませんが、B の 490 行は破棄されています。_history_longには、A は 5 行、B は 500 行が含まれています。 テーブルの最大サイズは 10,000 行であるため、いずれのスレッドでも破棄された行はありません。
実行の 5 分 (300 秒) 後:
A および B は、それぞれ 300 および 30,000 個のイベントを生成しました。
_historyには、A に 10 行、B に 10 行が含まれています。 スレッド当たりの記憶域は 10 行に制限されているため、A の 290 行は破棄されましたが、B の 29,990 行は破棄されました。 A の行には最大 10 秒経過したデータが含まれ、B の行には最大 .1 秒経過したデータのみが含まれます。_history_longには 10,000 行が含まれます。 A と B はともに 101 イベント/秒を生成するため、テーブルには A ではなく B から約 100 から 1 の行が混在した、約 10,000/101 = 99 秒前までのデータが含まれます。