MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む

このページは機械翻訳したものです。

27.9 現在および過去のイベントのパフォーマンススキーマテーブル

wait、stage、statement、および transaction イベントの場合、パフォーマンススキーマは現在のイベントをモニターおよび格納できます。 また、イベントが終了すると、パフォーマンススキーマはそれらを履歴テーブルに格納できます。 イベントタイプごとに、パフォーマンススキーマは現在のイベントと履歴イベントの格納に 3 つのテーブルを使用します。 テーブルには次の形式の名前があります。ここで、xxx はイベントタイプ (waits, stages, statements, transactions) を示します:

各イベントタイプの_current テーブルにはスレッドごとに 1 つの行が含まれるため、その最大サイズを構成するためのシステム変数はありません。 パフォーマンススキーマは、個々の履歴テーブルを説明するセクションに示されているように、テーブル固有のシステム変数を使用して、サーバーの起動時に履歴テーブルのサイズを自動設定するか、サイズを明示的に構成できます。 一般的な自動サイズ設定された値は、_history テーブルではスレッドごとに 10 行、_history_long テーブルでは合計 10,000 行です。

イベントタイプごとに、_current_history および_history_long の各テーブルに同じカラムがあります。 _current テーブルと_history テーブルのインデックス付けは同じです。 _history_long テーブルにインデックス付けがありません。

_current テーブルには、サーバー内で現在何が起こっているかが表示されます。 現在のイベントが終了すると、その_current テーブルから削除されます。

_history および_history_long のテーブルには、最近行われたことが表示されます。 履歴テーブルがいっぱいになると、新しいイベントが追加されると古いイベントは破棄されます。 テーブルの目的が異なるため、_history テーブルと_history_long テーブルの行は様々な方法で期限切れになります:

2 つのタイプの履歴テーブルの違いは、データ保存ポリシーに関連します。 イベントが最初に表示されたときに、両方のテーブルに同じデータが含まれています。 ただし、各テーブル内のデータは時間の経過とともに異なる期限が切れるため、各テーブルでデータが長期間または短時間保持される可能性があります:

スレッドが終了すると、そのすべての行は_history テーブルから破棄されますが、_history_long テーブルからは破棄されません。

次の例は、2 つのタイプの履歴テーブルに対してイベントを追加および破棄する方法の違いを示しています。 原則はすべてのイベントタイプに均等に適用されます。 この例は、次の前提に基づいています:

5 秒後:

実行の 5 分 (300 秒) 後: