このページは機械翻訳したものです。
setup_instruments テーブルは、イベントを収集できるインストゥルメントされたオブジェクトのクラスを一覧表示します。
mysql> SELECT * FROM performance_schema.setup_instruments\G*************************** 1. row *************************** NAME: wait/synch/mutex/pfs/LOCK_pfs_share_list ENABLED: NO TIMED: NO PROPERTIES: singleton VOLATILITY: 1DOCUMENTATION: Components can provide their own performance_schema tables. This lock protects the list of such tables definitions....*************************** 369. row *************************** NAME: stage/sql/executing ENABLED: NO TIMED: NO PROPERTIES: VOLATILITY: 0DOCUMENTATION: NULL...*************************** 687. row *************************** NAME: statement/abstract/Query ENABLED: YES TIMED: YES PROPERTIES: mutable VOLATILITY: 0DOCUMENTATION: SQL query just received from the network. At this point, the real statement type is unknown, the type will be refined after SQL parsing....*************************** 696. row *************************** NAME: memory/performance_schema/metadata_locks ENABLED: YES TIMED: NULL PROPERTIES: global_statistics VOLATILITY: 1DOCUMENTATION: Memory used for table performance_schema.metadata_locks... ソースコードに追加された各インストゥルメントは、インストゥルメントコードが実行されない場合でも、setup_instruments テーブルの行を提供します。 インストゥルメントが有効化されて実行されると、インストゥルメントされたインスタンスが作成され、file_instances やrwlock_instances などのxxx_instances
ほとんどのsetup_instruments 行を変更すると、すぐに監視に影響します。 一部のインストゥルメントでは、変更はサーバーの起動時にのみ有効です。実行時に変更しても効果はありません。 これは主にサーバー内の mutex、条件、および rwlocks に影響しますが、これが当てはまるほかのインストゥルメントが存在する可能性があります。
イベントフィルタリングにおけるsetup_instruments テーブルの役割の詳細については、セクション27.4.3「イベントの事前フィルタリング」を参照してください。
setup_instruments テーブルにはこれらのカラムがあります。
NAMEインストゥルメント名。セクション27.6「パフォーマンススキーマインストゥルメント命名規則」に説明するように、インストゥルメント名には複数の部分があり、階層を形成することがあります。 インストゥルメントの実行から生成されるイベントには、インストゥルメント
NAME値から取得されるEVENT_NAME値があります。 (イベントには実際には「名前」がありませんが、これによって、イベントをインストゥルメントに関連付ける方法を提供します。)ENABLEDインストゥルメントが有効にされているかどうか。 値は
YESまたはNOです。 無効にされたインストゥルメントはイベントを生成しません。 このカラムは変更できますが、ENABLEDの設定は、すでに作成されているインストゥルメントには影響しません。TIMEDインストゥルメントの時間が測定されるかどうか。 値は、
YES、NOまたはNULLです。 このカラムは変更できますが、TIMEDの設定は、すでに作成されているインストゥルメントには影響しません。TIMED値NULLは、インストゥルメントがタイミングをサポートしていないことを示します。 たとえば、メモリー操作は時間指定されていないため、そのTIMEDカラムはNULLです。タイミングをサポートするインストゥルメントに対して
TIMEDをNULLに設定しても、タイミングをサポートしないインストゥルメントに対してTIMEDをNULL以外に設定しても効果はありません。有効にされたインストゥルメントの時間が測定されない場合、インストゥルメントコードは有効ですが、タイマーは有効ではありません。 インストゥルメントによって生成されたイベントの
TIMER_START、TIMER_END、およびTIMER_WAITタイマー値がNULLになります。 これによって、サマリーテーブルの合計、最小、最大、および平均の時間値の計算時に、それらの値が無視されます。PROPERTIESインストゥルメントプロパティ。 このカラムは
SETデータ型を使用するため、インストゥルメントごとに次のリストの複数のフラグを設定できます:global_statistics: インストゥルメントはグローバルサマリーのみを生成します。 スレッドごと、アカウントごと、ユーザーごと、ホストごとなど、より詳細なレベルのサマリーは使用できません。 たとえば、ほとんどのメモリーインストゥルメントではグローバルサマリーのみが生成されます。mutable: インストゥルメントは、より具体的なものに「mutate」 できます。 このプロパティは、ステートメントインストゥルメントにのみ適用されます。progress: インストゥルメントは進捗データをレポートできます。 このプロパティはステージインストゥルメントにのみ適用されます。singleton: インストゥルメントには単一のインスタンスがあります。 たとえば、サーバー内のほとんどのグローバル mutex ロックはシングルトンであるため、対応するインストゥルメントも同様です。user: インストゥルメントは、(システムワークロードではなく) ユーザーワークロードに直接関連しています。 そのようなインストゥルメントには、wait/io/socket/sql/client_connectionがあります。
VOLATILITYインストゥルメントのボラティリティ。 ボラティリティ値の範囲は、低から高です。 値は、
mysql/psi/psi_base.hヘッダーファイルで定義されているPSI_VOLATILITY_定数に対応します:xxx#define PSI_VOLATILITY_UNKNOWN 0#define PSI_VOLATILITY_PERMANENT 1#define PSI_VOLATILITY_PROVISIONING 2#define PSI_VOLATILITY_DDL 3#define PSI_VOLATILITY_CACHE 4#define PSI_VOLATILITY_SESSION 5#define PSI_VOLATILITY_TRANSACTION 6#define PSI_VOLATILITY_QUERY 7#define PSI_VOLATILITY_INTRA_QUERY 8VOLATILITYカラムは、ユーザー (およびパフォーマンススキーマコード) にインストゥルメントの実行時動作に関するヒントを提供するための単なる情報です。低揮発性インデックス (PERMANENT = 1) を持つインストゥルメントは、サーバーの起動時に一度作成され、通常のサーバー操作中に破棄または再作成されることはありません。 これらは、サーバーの停止中にのみ破棄されます。
たとえば、
wait/synch/mutex/pfs/LOCK_pfs_share_listmutex は揮発性 1 で定義されており、これは一度作成されることを意味します。 インストゥルメンテーション自体から発生する可能性のあるオーバーヘッド (相互排他ロック初期化) は、このインストゥルメントには影響しません。 実行時オーバーヘッドは、mutex をロックまたはロック解除する場合にのみ発生します。ボラティリティインデックスが高いインストゥルメント (SESSION = 5 など) は、ユーザーセッションごとに作成および破棄されます。 たとえば、
wait/synch/mutex/sql/THD::LOCK_query_planmutex は、セッションが接続されるたびに作成され、セッションが切断されると破棄されます。この mutex は、パフォーマンススキーマのオーバーヘッドにより機密性が高くなります。これは、オーバーヘッドがロックおよびロック解除インストゥルメンテーションだけでなく、より頻繁に実行される相互排他ロック作成および破棄インストゥルメンテーションからも発生するためです。
ボラティリティの別の側面は、
ENABLEDカラムの更新が実際になんらかの影響を与えるかどうかと、そのタイミングに関するものです:ENABLEDの更新は、後で作成されるインストゥルメントされたオブジェクトに影響しますが、すでに作成されているインストゥルメントには影響しません。より多くの「volatile」 のインストゥルメントでは、
setup_instrumentsテーブルの新しい設定がより早く使用されます。
たとえば、次のステートメントは既存のセッションの
LOCK_query_planmutex には影響しませんが、更新後に作成された新しいセッションには影響します:UPDATE performance_schema.setup_instrumentsSET ENABLED=valueWHERE NAME = 'wait/synch/mutex/sql/THD::LOCK_query_plan';このステートメントは、実際には何の効果もありません:
UPDATE performance_schema.setup_instrumentsSET ENABLED=valueWHERE NAME = 'wait/synch/mutex/pfs/LOCK_pfs_share_list';この mutex は永続的であり、更新の実行前にすでに作成されています。 mutex が再度作成されることはないため、
setup_instrumentsのENABLED値は使用されません。 この mutex を有効または無効にするには、かわりにmutex_instancesテーブルを使用します。DOCUMENTATIONインストゥルメントの目的を説明する文字列。 説明がない場合、値は
NULLです。
setup_instruments テーブルには次のインデックスがあります:
主キー (
NAME)
TRUNCATE TABLE は、setup_instruments テーブルに対して許可されていません。