パフォーマンススキーマタイマーは、精度とオーバーヘッドの量が異なります。 使用可能なタイマーとそれらの特性を確認するには、performance_timers テーブルをチェックしてください。

mysql> SELECT * FROM performance_schema.performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE       |      2389029850 |                1 |             72 |
| NANOSECOND  |      1000000000 |                1 |            112 |
| MICROSECOND |         1000000 |                1 |            136 |
| MILLISECOND |            1036 |                1 |            168 |
+-------------+-----------------+------------------+----------------+

特定のタイマーに関連付けられた値が NULL の場合、そのタイマーはプラットフォームでサポートされていません。

カラムの意味は次のとおりです:

パフォーマンススキーマは、次のようにタイマーを割り当てます:

サーバーの起動時に、パフォーマンススキーマは構築時にタイマーの割り当てに関する仮定が正しいことを検証し、タイマーが使用できない場合は警告を表示します。

待機イベントを時間するには、タイマーの精度を犠牲にしてオーバーヘッドを削減することが最も重要な基準であるため、CYCLE タイマーを使用することをお薦めします。

ステートメント (またはステージ) の実行にかかる時間は、一般に単一の待機の実行にかかる時間より桁違いに大きくなります。 ステートメントの時間を測定するために、もっとも重要な基準は、プロセッサの周波数の変更に影響を受けない正確な測定基準を設定することであるため、サイクルに基づいていないタイマーを使用することがもっとも適切です。 ステートメントのデフォルトのタイマーは NANOSECOND です。 CYCLE タイマーと比較すると、余分な「「オーバーヘッド」」は重要ではありません。これは、タイマーのコールによって発生するオーバーヘッド (ステートメントの開始時に一度、終了時に一度) が、ステートメント自体の実行に使用される CPU 時間と比較して大幅に低いためです。 CYCLE タイマーを使用することにはメリットがなく、欠点だけです。

サイクルカウンタによって提供される精度はプロセッサ速度によって異なります。 プロセッサが 1 GHz (10 億サイクル/秒) 以上で実行する場合、サイクルカウンタはナノ秒未満の精度を実現します。 サイクルカウンタを使用することは、実際の時間を取得するより、はるかに負荷が小さくなります。 たとえば、標準 gettimeofday() 関数は数百サイクルかかる可能性があり、これは 1 秒あたり数千または数百万回発生する可能性のあるデータ収集では、許容できないオーバーヘッドです。

サイクルカウンタには欠点もあります。

MySQL は、x386 (Windows、macOS、Linux、Solaris、その他の UNIX フレーバ)、PowerPC、IA-64 のサイクルカウンタで動作します。

現在のイベントおよび履歴イベントを格納する「パフォーマンススキーマ」テーブルの行には、タイミング情報をテーブルす 3 つのカラムがあります: TIMER_START および TIMER_END はイベントがいつ開始および終了したかを示し、TIMER_WAIT はイベント期間を示します。

setup_instruments テーブルにはイベントを収集するインストゥルメントを示す ENABLED カラムがあります。 このテーブルには、時間が測定されるインストゥルメントを示す TIMED カラムもあります。 インストゥルメントが有効にされていない場合、イベントを生成しません。 有効にされているインストゥルメントの時間が測定されない場合、インストゥルメントによって生成されたイベントの TIMER_START、TIMER_END、および TIMER_WAIT タイマー値が NULL になります。 これにより、サマリーテーブルの集計時間値 (合計、最小、最大および平均) の計算時にこれらの値が無視されます。

内部的には、イベント内の時間は、イベントタイミングの開始時に有効なタイマーで指定された単位で格納されます。 イベントが「パフォーマンススキーマ」テーブルから取得されたときに表示されるように、時間はピコ秒 (1 秒に 1 兆) で表示され、選択されているタイマーに関係なく標準単位に正規化されます。

サーバー起動時のパフォーマンススキーマの初期化で、タイマーベースライン (「時間ゼロ」) が発生します。 イベント内の TIMER_START および TIMER_END 値はベースライン以降のピコ秒を表します。 TIMER_WAIT 値はピコ秒での期間です。

イベント内のピコ秒値は概算です。 それらの精度は、ある単位から別の単位への変換に伴う通常の誤差の形式に左右されます。 CYCLE タイマーが使われ、プロセッサのレートがさまざまに異なる場合、ドリフトが発生することがあります。 このため、サーバーの起動から経過した時間の正確な測定基準として、イベントの TIMER_START 値を見ることは妥当ではありません。 一方、開始時間や期間によって、イベントを順序付けるために、ORDER BY 句に TIMER_START 値または TIMER_WAIT 値を使用することは適切です。

イベントでマイクロ秒などの値ではなく、ピコ秒を選択したことには、パフォーマンス上の根拠があります。 1 つの実装目標は、タイマーに関係なく、統一された時間単位で結果を表示することでした。 理想の世界では、この時間単位は時計の単位のように見え、適度に正確である、つまりマイクロ秒です。 ただし、サイクルまたはナノ秒をマイクロ秒に変換するには、すべてのインストゥルメンテーションで除算を実行する必要がある場合があります。 除算は多くのプラットフォームで高い負荷がかかります。 乗算は負荷が高くないため、それを使用しています。 そのため、時間単位は、大きな精度の損失がないように十分に大きな乗数を使用した、可能なかぎり最大の TIMER_FREQUENCY 値の整数の倍数です。 その結果、時間単位が「ピコ秒」になります。 この精度は疑似ですが、この決定によりオーバーヘッドを最小にすることができます。

wait、stage、statement、または transaction イベントの実行中、各 current-event テーブルには現在のイベントのタイミング情報が表示されます:

events_waits_current
events_stages_current
events_statements_current
events_transactions_current

完了していないイベントが実行されている期間を判別できるように、タイマーカラムは次のように設定されます:

まだ完了していないイベントの END_EVENT_ID 値は NULL です。 イベントについてこれまでに経過した時間を評価するには、TIMER_WAIT カラムを使用します。 したがって、まだ完了しておらず、これまでに N ピコ秒より長くかかったイベントを識別するために、モニタリングアプリケーションはクエリーで次の式を使用できます:

WHERE END_EVENT_ID IS NULL AND TIMER_WAIT > N

前述のイベント識別では、対応するインストゥルメントの ENABLED および TIMED が YES に設定されており、関連するコンシューマが有効になっていることを前提としています。