ステートメント要約表
SQL パフォーマンスの問題をより適切に処理するために、MySQL はperformance_schemaのステートメント要約表を提供して、SQL を統計で監視します。これらのテーブルの中で、 events_statements_summary_by_digestは、レイテンシー、実行時間、スキャンされた行、およびフル テーブル スキャンなどの豊富なフィールドを使用して、SQL の問題を特定するのに非常に役立ちます。
したがって、v4.0.0-rc.1 から、TiDB はevents_statements_summary_by_digestに似た機能を持つシステム テーブルをinformation_schema ( performance_schemaではなく) で提供します。
statements_summarystatements_summary_historycluster_statements_summarycluster_statements_summary_historystatements_summary_evicted
このドキュメントでは、これらのテーブルについて詳しく説明し、それらを使用して SQL パフォーマンスの問題をトラブルシューティングする方法を紹介します。
statements_summary
statements_summaryはinformation_schemaのシステム テーブルです。 statements_summaryは、SQL ダイジェストとプラン ダイジェストによって SQL ステートメントをグループ化し、各 SQL カテゴリの統計を提供します。
ここでの「SQL ダイジェスト」とは、スロー ログで使用されるのと同じ意味で、正規化された SQL ステートメントによって計算された一意の識別子です。正規化プロセスでは、定数の空白文字は無視され、大文字と小文字は区別されません。したがって、一貫した構文を持つステートメントは、同じダイジェストを持ちます。例えば：
SELECT * FROM employee WHERE id IN (1, 2, 3) AND salary BETWEEN 1000 AND 2000;
select * from EMPLOYEE where ID in (4, 5) and SALARY between 3000 and 4000;
正規化後、それらは両方とも次のカテゴリになります。
select * from employee where id in (...) and salary between ? and ?;
ここでの「プラン ダイジェスト」とは、正規化された実行プランによって計算された一意の識別子を指します。正規化プロセスでは、定数は無視されます。同じステートメントが異なる実行計画を持つ可能性があるため、同じ SQL ステートメントが異なるカテゴリーにグループ化される場合があります。同じカテゴリの SQL ステートメントには、同じ実行計画があります。
statements_summaryは、SQL モニタリング メトリックの集計結果を格納します。一般に、各監視メトリックには最大値と平均値が含まれます。たとえば、実行レイテンシーメトリックは、 AVG_LATENCY (平均レイテンシー) とMAX_LATENCY (最大レイテンシー) の 2 つのフィールドに対応します。
監視メトリックが最新であることを確認するために、 statements_summaryテーブルのデータは定期的にクリアされ、最近の集計結果のみが保持されて表示されます。定期的なデータ消去は、システム変数tidb_stmt_summary_refresh_intervalによって制御されます。クリア直後にクエリを実行すると、表示されるデータが非常に少なくなる場合があります。
以下は、クエリstatements_summaryのサンプル出力です。
SUMMARY_BEGIN_TIME: 2020-01-02 11:00:00
SUMMARY_END_TIME: 2020-01-02 11:30:00
STMT_TYPE: Select
SCHEMA_NAME: test
DIGEST: 0611cc2fe792f8c146cc97d39b31d9562014cf15f8d41f23a4938ca341f54182
DIGEST_TEXT: select * from employee where id = ?
TABLE_NAMES: test.employee
INDEX_NAMES: NULL
SAMPLE_USER: root
EXEC_COUNT: 3
SUM_LATENCY: 1035161
MAX_LATENCY: 399594
MIN_LATENCY: 301353
AVG_LATENCY: 345053
AVG_PARSE_LATENCY: 57000
MAX_PARSE_LATENCY: 57000
AVG_COMPILE_LATENCY: 175458
MAX_COMPILE_LATENCY: 175458
...........
AVG_MEM: 103
MAX_MEM: 103
AVG_DISK: 65535
MAX_DISK: 65535
AVG_AFFECTED_ROWS: 0
FIRST_SEEN: 2020-01-02 11:12:54
LAST_SEEN: 2020-01-02 11:25:24
QUERY_SAMPLE_TEXT: select * from employee where id=3100
PREV_SAMPLE_TEXT:
PLAN_DIGEST: f415b8d52640b535b9b12a9c148a8630d2c6d59e419aad29397842e32e8e5de3
PLAN: Point_Get_1 root 1 table:employee, handle:3100
ノート：
TiDB では、ステートメント サマリー テーブルのフィールドの時間単位はナノ秒 (ns) ですが、MySQL では時間単位はピコ秒 (ps) です。
statements_summary_history
statements_summary_historyのテーブル スキーマはstatements_summaryのテーブル スキーマと同じです。 statements_summary_historyは、時間範囲の履歴データを保存します。履歴データを確認することで、異常をトラブルシューティングし、さまざまな時間範囲のモニタリング メトリックを比較できます。
フィールドSUMMARY_BEGIN_TIMEとSUMMARY_END_TIMEは、履歴時間範囲の開始時刻と終了時刻を表します。
statements_summary_evicted
tidb_stmt_summary_max_stmt_count変数は、 statement_summaryテーブルがメモリに格納するステートメントの最大数を制御します。 statement_summaryテーブルは LRU アルゴリズムを使用します。 SQL ステートメントの数がtidb_stmt_summary_max_stmt_countの値を超えると、最長の未使用レコードがテーブルから削除されます。各期間中に排除された SQL ステートメントの数は、 statements_summary_evictedテーブルに記録されます。
statements_summary_evictedテーブルは、SQL レコードがstatement_summaryテーブルから削除された場合にのみ更新されます。 statements_summary_evictedは、エビクションが発生した期間と、エビクトされた SQL ステートメントの数のみを記録します。
ステートメント要約用のcluster表
statements_summary 、およびstatements_summary_historyの表は、単一のstatements_summary_evictedサーバーのステートメントの要約のみを示しています。クラスター全体のデータをクエリするには、 cluster_statements_summary 、 cluster_statements_summary_history 、またはcluster_statements_summary_evictedテーブルをクエリする必要があります。
cluster_statements_summaryは、各 TiDBサーバーのstatements_summaryのデータを表示します。 cluster_statements_summary_historyは、各 TiDBサーバーのstatements_summary_historyのデータを表示します。 cluster_statements_summary_evictedは、各 TiDBサーバーのstatements_summary_evictedのデータを表示します。これらのテーブルは、 INSTANCEフィールドを使用して TiDBサーバーのアドレスを表します。その他のフィールドはstatements_summaryと同じです。
パラメータ構成
次のシステム変数は、ステートメントの要約を制御するために使用されます。
tidb_enable_stmt_summary: ステートメント要約機能を有効にするかどうかを決定します。1はenableを表し、0はdisableを意味します。この機能はデフォルトで有効になっています。この機能を無効にすると、システム テーブルの統計情報がクリアされます。次回この機能を有効にしたときに、統計が再計算されます。テストでは、この機能を有効にしてもパフォーマンスにほとんど影響がないことが示されています。tidb_stmt_summary_refresh_interval:statements_summaryテーブルが更新される間隔。時間の単位は秒です。デフォルト値は1800です。tidb_stmt_summary_history_size:statements_summary_historyテーブルに格納されている各 SQL ステートメント カテゴリのサイズ。これは、statement_summary_evictedテーブルの最大レコード数でもあります。デフォルト値は24です。tidb_stmt_summary_max_stmt_count: ステートメント要約テーブルに保管できる SQL ステートメントの数を制限します。デフォルト値は3000です。制限を超えると、最近使用されていない SQL ステートメントがクリアされます。これらのクリアされた SQL ステートメントは、statement_summary_evictedテーブルに記録されます。tidb_stmt_summary_max_sql_length:DIGEST_TEXTとQUERY_SAMPLE_TEXTの最長表示長を指定します。デフォルト値は4096です。tidb_stmt_summary_internal_query: TiDB SQLステートメントをカウントするかどうかを決定します。1は数えることを意味し、0は数えないことを意味します。デフォルト値は0です。
ノート：
tidb_stmt_summary_max_stmt_countの制限を超えたために SQL ステートメントのカテゴリを削除する必要がある場合、TiDB は、すべての時間範囲のその SQL ステートメント カテゴリのデータをstatement_summary_historyテーブルから削除します。そのため、一定時間範囲内のSQL文のカテゴリ数が上限に達していなくても、statement_summary_historyのテーブルに格納されるSQL文の数は、実際のSQL文の数よりも少なくなります。この状況が発生してパフォーマンスに影響する場合は、値tidb_stmt_summary_max_stmt_countを増やすことをお勧めします。
ステートメントの要約構成の例を以下に示します。
set global tidb_enable_stmt_summary = true;
set global tidb_stmt_summary_refresh_interval = 1800;
set global tidb_stmt_summary_history_size = 24;
上記の構成が有効になると、30 分ごとにstatements_summaryのテーブルがクリアされます。 statements_summary_historyテーブルには、最近 12 時間にわたって生成されたデータが格納されます。
statements_summary_evictedテーブルは、SQL ステートメントがステートメントの要約から削除された最近の 24 期間を記録します。 statements_summary_evictedテーブルは 30 分ごとに更新されます。
ノート：
tidb_stmt_summary_history_size、tidb_stmt_summary_max_stmt_count、およびtidb_stmt_summary_max_sql_lengthの構成アイテムは、メモリ使用量に影響します。ニーズ、SQL サイズ、SQL 数、およびマシン構成に基づいて、これらの構成を調整することをお勧めします。大きすぎる値を設定することはお勧めしません。tidb_stmt_summary_history_sizetidb_stmt_summary_max_stmt_counttidb_stmt_summary_max_sql_length*3を使用してメモリ使用量を計算できます。
ステートメントの要約に適切なサイズを設定する
システムが一定期間 (システムの負荷に応じて) 実行された後、 statement_summaryのテーブルをチェックして、SQL エビクションが発生したかどうかを確認できます。例えば：
select @@global.tidb_stmt_summary_max_stmt_count;
select count(*) from information_schema.statements_summary;
+-------------------------------------------+
| @@global.tidb_stmt_summary_max_stmt_count |
+-------------------------------------------+
| 3000 |
+-------------------------------------------+
1 row in set (0.001 sec)
+----------+
| count(*) |
+----------+
| 3001 |
+----------+
1 row in set (0.001 sec)
statements_summaryテーブルがレコードでいっぱいであることがわかります。次に、 statements_summary_evictedテーブルから削除されたデータを確認します。
select * from information_schema.statements_summary_evicted;
+---------------------+---------------------+---------------+
| BEGIN_TIME | END_TIME | EVICTED_COUNT |
+---------------------+---------------------+---------------+
| 2020-01-02 16:30:00 | 2020-01-02 17:00:00 | 59 |
+---------------------+---------------------+---------------+
| 2020-01-02 16:00:00 | 2020-01-02 16:30:00 | 45 |
+---------------------+---------------------+---------------+
2 row in set (0.001 sec)
上記の結果から、最大 59 の SQL カテゴリが削除されていることがわかります。これは、ステートメントの要約の適切なサイズが 59 レコードであることを示しています。
制限
ステートメント要約テーブルには、次の制限があります。
上記のステートメント要約テーブルのすべてのデータは、TiDBサーバーを再起動すると失われます。これは、ステートメント サマリー テーブルがすべてメモリ テーブルであり、データがストレージに永続化されるのではなく、メモリにキャッシュされるためです。
トラブルシューティングの例
このセクションでは、ステートメントの要約機能を使用して SQL パフォーマンスの問題をトラブルシューティングする方法を示す 2 つの例を示します。
サーバー側が原因で SQLレイテンシーが高くなる可能性はありますか?
この例では、クライアントはemployeeテーブルに対するポイント クエリでパフォーマンスが低下しています。 SQL テキストに対してあいまい検索を実行できます。
SELECT avg_latency, exec_count, query_sample_text
FROM information_schema.statements_summary
WHERE digest_text LIKE 'select * from employee%';
1msと0.3msはavg_latencyの通常の範囲内と見なされます。したがって、サーバー側が原因ではないと結論付けることができます。クライアントまたはネットワークでトラブルシューティングできます。
+-------------+------------+------------------------------------------+
| avg_latency | exec_count | query_sample_text |
+-------------+------------+------------------------------------------+
| 1042040 | 2 | select * from employee where name='eric' |
| 345053 | 3 | select * from employee where id=3100 |
+-------------+------------+------------------------------------------+
2 rows in set (0.00 sec)
合計時間が最も長い SQL ステートメントのカテゴリはどれですか?
QPS が 10:00 から 10:30 に大幅に減少した場合、履歴テーブルから、消費時間が最も長い SQL ステートメントの 3 つのカテゴリを見つけることができます。
SELECT sum_latency, avg_latency, exec_count, query_sample_text
FROM information_schema.statements_summary_history
WHERE summary_begin_time='2020-01-02 10:00:00'
ORDER BY sum_latency DESC LIMIT 3;
結果は、次の 3 つのカテゴリの SQL ステートメントが合計で最も長い時間を費やしていることを示しており、優先度を高くして最適化する必要があります。
+-------------+-------------+------------+-----------------------------------------------------------------------+
| sum_latency | avg_latency | exec_count | query_sample_text |
+-------------+-------------+------------+-----------------------------------------------------------------------+
| 7855660 | 1122237 | 7 | select avg(salary) from employee where company_id=2013 |
| 7241960 | 1448392 | 5 | select * from employee join company on employee.company_id=company.id |
| 2084081 | 1042040 | 2 | select * from employee where name='eric' |
+-------------+-------------+------------+-----------------------------------------------------------------------+
3 rows in set (0.00 sec)
フィールドの説明
statements_summaryフィールドの説明
以下は、 statements_summaryテーブルのフィールドの説明です。
基本フィールド:
STMT_TYPE: SQL ステートメントのタイプ。SCHEMA_NAME: このカテゴリの SQL ステートメントが実行される現在のスキーマ。DIGEST: このカテゴリの SQL ステートメントのダイジェスト。DIGEST_TEXT: 正規化された SQL ステートメント。QUERY_SAMPLE_TEXT: SQL カテゴリの元の SQL ステートメント。元のステートメントは 1 つだけ取得されます。TABLE_NAMES: SQL ステートメントに含まれるすべてのテーブル。複数のテーブルがある場合は、それぞれをカンマで区切ります。INDEX_NAMES: SQL ステートメントで使用されるすべての SQL インデックス。複数のインデックスがある場合は、それぞれをカンマで区切ります。SAMPLE_USER: このカテゴリの SQL ステートメントを実行するユーザー。 1 人のユーザーのみが取得されます。PLAN_DIGEST: 実行計画のダイジェスト。PLAN: 元の実行計画。複数のステートメントがある場合は、1 つのステートメントのみのプランが採用されます。BINARY_PLAN: バイナリ形式でエンコードされた元の実行計画。複数のステートメントがある場合は、1 つのステートメントのみのプランが採用されます。SELECT tidb_decode_binary_plan('xxx...')ステートメントを実行して、特定の実行計画を解析します。PLAN_CACHE_HITS: このカテゴリの SQL ステートメントがプラン キャッシュにヒットした合計回数。PLAN_IN_CACHE: このカテゴリの SQL ステートメントの以前の実行がプラン キャッシュにヒットしたかどうかを示します。
実行時間に関連するフィールド:
SUMMARY_BEGIN_TIME: 現在の集計期間の開始時刻。SUMMARY_END_TIME: 現在の集計期間の終了時刻。FIRST_SEEN: このカテゴリの SQL ステートメントが初めて表示された時刻。LAST_SEEN: このカテゴリの SQL ステートメントが最後に表示された時刻。
TiDBサーバーに関連するフィールド:
EXEC_COUNT: このカテゴリの SQL ステートメントの合計実行時間。SUM_ERRORS: 実行中に発生したエラーの合計。SUM_WARNINGS: 実行中に発生した警告の合計。SUM_LATENCY: このカテゴリの SQL ステートメントの合計実行レイテンシー。MAX_LATENCY: このカテゴリの SQL ステートメントの最大実行レイテンシー。MIN_LATENCY: このカテゴリの SQL ステートメントの最小実行レイテンシー。AVG_LATENCY: このカテゴリの SQL ステートメントの平均実行レイテンシー。AVG_PARSE_LATENCY: パーサーの平均レイテンシー。MAX_PARSE_LATENCY: パーサーの最大レイテンシー。AVG_COMPILE_LATENCY: コンパイラの平均レイテンシー。MAX_COMPILE_LATENCY: コンパイラの最大レイテンシー。AVG_MEM: 使用された平均メモリ (バイト)。MAX_MEM: 使用される最大メモリ (バイト)。AVG_DISK: 使用された平均ディスク容量 (バイト)。MAX_DISK: 使用されている最大ディスク容量 (バイト)。
TiKV コプロセッサ タスクに関連するフィールド:
SUM_COP_TASK_NUM: 送信されたコプロセッサー要求の総数。MAX_COP_PROCESS_TIME: コプロセッサー・タスクの最大実行時間。MAX_COP_PROCESS_ADDRESS: 実行時間が最大のコプロセッサー・タスクのアドレス。MAX_COP_WAIT_TIME: コプロセッサー・タスクの最大待ち時間。MAX_COP_WAIT_ADDRESS: 待ち時間が最大のコプロセッサー・タスクのアドレス。AVG_PROCESS_TIME: TiKV での SQL ステートメントの平均処理時間。MAX_PROCESS_TIME: TiKV での SQL ステートメントの最大処理時間。AVG_WAIT_TIME: TiKV での SQL ステートメントの平均待機時間。MAX_WAIT_TIME: TiKV での SQL ステートメントの最大待機時間。AVG_BACKOFF_TIME: SQL ステートメントで再試行が必要なエラーが発生した場合の再試行までの平均待機時間。MAX_BACKOFF_TIME: SQL ステートメントで再試行が必要なエラーが発生した場合の再試行までの最大待機時間。AVG_TOTAL_KEYS: コプロセッサーがスキャンしたキーの平均数。MAX_TOTAL_KEYS: コプロセッサーがスキャンしたキーの最大数。AVG_PROCESSED_KEYS: コプロセッサーが処理したキーの平均数。avg_total_keysと比較して、avg_processed_keysには古いバージョンの MVCC が含まれていません。avg_total_keysとavg_processed_keysの大きな違いは、多くの古いバージョンが存在することを示しています。MAX_PROCESSED_KEYS: コプロセッサーが処理したキーの最大数。
トランザクション関連のフィールド:
AVG_PREWRITE_TIME: プリライト フェーズの平均時間。MAX_PREWRITE_TIME: プリライト フェーズの最長時間。AVG_COMMIT_TIME: コミット フェーズの平均時間。MAX_COMMIT_TIME: コミット フェーズの最長時間。AVG_GET_COMMIT_TS_TIME:commit_tsを取得する平均時間。MAX_GET_COMMIT_TS_TIME:commit_tsを取得する最長時間。AVG_COMMIT_BACKOFF_TIME: コミット・フェーズ中にSQL文で再試行が必要なエラーが発生した場合の再試行までの平均待機時間。MAX_COMMIT_BACKOFF_TIME: コミット・フェーズ中にSQL文で再試行が必要なエラーが発生した場合の再試行までの最大待機時間。AVG_RESOLVE_LOCK_TIME: トランザクション間で発生したロックの競合を解決するための平均時間。MAX_RESOLVE_LOCK_TIME: トランザクション間で発生したロックの競合を解決するための最長時間。AVG_LOCAL_LATCH_WAIT_TIME: ローカル トランザクションの平均待機時間。MAX_LOCAL_LATCH_WAIT_TIME: ローカル トランザクションの最大待機時間。AVG_WRITE_KEYS: 書き込まれたキーの平均数。MAX_WRITE_KEYS: 書き込まれたキーの最大数。AVG_WRITE_SIZE: 書き込まれたデータの平均量 (バイト単位)。MAX_WRITE_SIZE: 書き込まれたデータの最大量 (バイト単位)。AVG_PREWRITE_REGIONS: 事前書き込みフェーズに含まれるリージョンの平均数。MAX_PREWRITE_REGIONS: 事前書き込みフェーズ中のリージョンの最大数。AVG_TXN_RETRY: トランザクション再試行の平均回数。MAX_TXN_RETRY: トランザクション再試行の最大数。SUM_BACKOFF_TIMES: このカテゴリの SQL ステートメントで再試行が必要なエラーが発生した場合の再試行の合計。BACKOFF_TYPES: 再試行が必要なすべてのタイプのエラーと、各タイプの再試行回数。フィールドの形式はtype:numberです。複数のエラー タイプがある場合は、それぞれをtxnLock:2,pdRPC:1のようにコンマで区切ります。AVG_AFFECTED_ROWS: 影響を受ける行の平均数。PREV_SAMPLE_TEXT: 現在の SQL ステートメントがCOMMITの場合、PREV_SAMPLE_TEXTはCOMMITまでの前のステートメントです。この場合、SQL ステートメントはダイジェストとprev_sample_textでグループ化されます。これは、異なるprev_sample_textのCOMMITステートメントが異なる行にグループ化されることを意味します。現在の SQL ステートメントがCOMMITでない場合、PREV_SAMPLE_TEXTフィールドは空の文字列です。
statements_summary_evictedフィールドの説明
BEGIN_TIME: 開始時刻を記録します。END_TIME: 終了時刻を記録します。EVICTED_COUNT: 記録期間中に削除された SQL カテゴリの数。