目次
- 22.1 パフォーマンススキーマクイックスタート
- 22.2 パフォーマンススキーマ構成
- 22.3 パフォーマンススキーマクエリー
- 22.4 パフォーマンススキーマインストゥルメント命名規則
- 22.5 パフォーマンススキーマステータスモニタリング
- 22.6 パフォーマンススキーマの原子的および分子的イベント
- 22.7 パフォーマンススキーマステートメントダイジェスト
- 22.8 パフォーマンススキーマの一般的なテーブル特性
- 22.9 パフォーマンススキーマテーブルの説明
- 22.10 パフォーマンススキーマオプションおよび変数リファレンス
- 22.11 パフォーマンススキーマコマンドオプション
- 22.12 パフォーマンススキーマシステム変数
- 22.13 パフォーマンススキーマステータス変数
- 22.14 パフォーマンススキーマとプラグイン
- 22.15 問題を診断するためのパフォーマンススキーマの使用
MySQL パフォーマンススキーマは低レベルで MySQL サーバーの実行をモニタリングするための機能です。パフォーマンススキーマには、これらの特性があります。
パフォーマンススキーマは、実行時にサーバーの内部実行を検査する方法を提供します。それは、
PERFORMANCE_SCHEMA
ストレージエンジンおよびperformance_schema
データベースを使用して実装されます。パフォーマンススキーマは、主にパフォーマンスデータに焦点を合わせています。これは、メタデータの検査に使用されるINFORMATION_SCHEMA
と異なります。パフォーマンススキーマはサーバーイベントをモニターします。「イベント」は、時間がかかり、タイミング情報を収集できるようにインストゥルメントされた、サーバーが実行するすべてのことです。一般に、イベントは、関数呼び出し、オペレーティングシステムの待機、解析やソートなどの SQL ステートメント実行のステージ、またはステートメント全体やステートメントのグループなどになります。現在、イベントコレクションは、サーバーおよびいくつかのストレージエンジンの同期呼び出し (相互排他ロックのためなど) のファイルおよびテーブル I/O、テーブルロックなどに関する情報へのアクセスを提供します。
パフォーマンススキーマイベントは、サーバーのバイナリログに書き込まれるイベント (これはデータの変更を説明する) やイベントスケジューラのイベント (これはストアドプログラムの一種である) とは区別されます。
パフォーマンススキーマイベントは MySQL サーバーの特定のインスタンスに固有です。MySQL 5.6.9 以降では、パフォーマンススキーマテーブルはサーバーにローカルとみなされ、それらへの変更はバイナリログにレプリケートされたり、書き込まれたりしません。(Bug #14741537)
現在のイベントに加えて、イベントの履歴とサマリーを取得できます。これにより、インストゥルメントされたアクティビティーが何回実行され、それらにどのくらいの時間がかかったかを判断できます。イベント情報を取得して、特定のスレッドのアクティビティー、または相互排他ロックやファイルなどの特定のオブジェクトに関連付けられているアクティビティーを表示できます。
PERFORMANCE_SCHEMA
ストレージエンジンは、サーバーソースコードで「インストゥルメンテーションポイント」を使用して、イベントデータを収集します。収集されたイベントは、
performance_schema
データベース内のテーブルに格納されます。これらのテーブルは、ほかのテーブルと同様にSELECT
ステートメントを使用してクエリーできます。パフォーマンススキーマの構成は、SQL ステートメントから
performance_schema
データベース内のテーブルを更新することによって、動的に変更できます。構成の変更はデータコレクションにすぐに影響しません。performance_schema
データベース内のテーブルは、永続的なディスク上ストレージを使用しないビューや一時テーブルです。-
モニタリングは MySQL でサポートされているすべてのプラットフォームで使用できます。
いくつかの制限が適用されることがあります。タイマーの種類はプラットフォームごとに異なることがあります。ストレージエンジンに適用されるインストゥルメントは、すべてのストレージエンジンに実装されていないことがあります。各サードパーティーエンジンのインストゥルメンテーションはエンジン管理者の責任です。セクションD.8「パフォーマンススキーマの制約」も参照してください。
データコレクションは、サーバーソースコードを変更し、インストゥルメンテーションを追加することによって実装されます。レプリケーションやイベントスケジューラなどのほかの機能と異なり、パフォーマンススキーマに関連付けられた個別のスレッドはありません。
パフォーマンススキーマは、サーバーパフォーマンスに与える影響を最小にしながら、サーバー実行に関する有益な情報へのアクセスを提供することを目的としています。実装はこれらの設計目標に従います。
パフォーマンススキーマのアクティブ化によって、サーバーの動作は変更されません。たとえば、それによってスレッドスケジューリングが変更されず、クエリー実行計画 (
EXPLAIN
によって表示される) が変更されません。サーバーの起動時に行われた以上のメモリー割り当ては行われません。固定サイズでの構造の早期割り当てを使用することで、それらのサイズ変更や再割り当てをする必要がなくなりますが、これは十分な実行時パフォーマンスの達成に重要です。
サーバーのモニタリングはごくわずかなオーバーヘッドで、継続的かつ目立たずに行われます。パフォーマンススキーマのアクティブ化によって、サーバーが使用不能になりません。
パーサーは変更されません。新しいキーワードやステートメントはありません。
パフォーマンススキーマが内部で失敗しても、サーバーコードの実行は正常に続行されます。
初期のイベントの収集時に処理を実行するか、あとのイベント取得時に処理を実行するかのどちらかを選択する場合、収集が速くなるほうが優先されます。これは、取得がオンデマンドで、まったく行われないこともあるのに対し、収集は進行中であるためです。
新しいインストゥルメンテーションポイントを追加することは簡単です。
インストゥルメンテーションはバージョン管理されます。インストゥルメンテーションの実装が変更された場合、以前にインストゥルメントされたコードが動作し続けます。これは、最新のパフォーマンススキーマの変更と同期させておくために、各プラグインをアップグレードする必要がないため、サードパーティープラグインの開発者にメリットがあります。