📣
TiDB Cloud Essential はパブリックプレビュー中です。このページは自動翻訳されたものです。原文はこちらからご覧ください。
AI
開発者向け
ベストプラクティス
API

明細書概要表

SQL のパフォーマンス問題をより適切に処理するために、MySQL は、統計情報を使用して SQL を監視するためのperformance_schemaの明細書概要表を提供しています。これらのテーブルの中でも、 events_statements_summary_by_digestは、レイテンシー、実行時間、スキャンされた行数、フルテーブルスキャンなどの豊富なフィールドを備えているため、SQL の問題を特定する際に非常に役立ちます。

したがって、v4.0.0-rc.1 以降、TiDB はinformation_schemaと機能面で類似したシステム テーブルをperformance_schema } events_statements_summary_by_digestではなく) で提供します。

注記：

上記の表は、 TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスでは利用できません。

このドキュメントでは、これらのテーブルの詳細を説明し、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）です。
  • v7.5.1 および v7.6.0 以降、 が有効にリソース制御ているクラスターでは、 statements_summaryリソース グループごとに集約されます。たとえば、異なるリソース グループで実行された同じステートメントは、異なるレコードとして収集されます。

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システム変数はstatements_summaryテーブルとstatements_summary_historyテーブルがメモリに格納できる SQL ダイジェストの総数を制限します。この制限を超えると、TiDB はstatements_summaryテーブルとstatements_summary_historyテーブルの両方から、最も使用頻度の低い SQL ダイジェストを削除します。

注記：

tidb_stmt_summary_enable_persistent有効になっている場合、 statements_summary_historyテーブルのデータはディスクに永続化されます。この場合、 tidb_stmt_summary_max_stmt_count 、 statements_summaryテーブルがメモリに格納できる SQL ダイジェストの数のみを制限し、{{B-PLACEHOLDER-5-PLACEHOLDER- tidb_stmt_summary_max_stmt_count statements_summaryから最も使用頻度の低い SQL ダイジェストのみを削除します。

statements_summary_evictedテーブルには、SQL ダイジェストが削除された期間と、その期間中に削除された SQL ダイジェストの数が記録されます。このテーブルはtidb_stmt_summary_max_stmt_countワークロードに対して適切に構成されているかどうかを評価するのに役立ちます。このテーブルにレコードが含まれている場合、SQL ダイジェストの数が、ある時点でtidb_stmt_summary_max_stmt_countを超えたことを示しています。

TiDBダッシュボードのSQLステートメントページでは、削除されたステートメントに関する情報がOthers行に表示されます。

ステートメントサマリーのclusterテーブル

statements_summary 、 statements_summary_history 、およびstatements_summary_evictedテーブルには、単一の TiDBサーバーのステートメントの概要のみが表示されます。クラスタ全体のデータを照会するには、 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 、 statements_summary_history 、およびstatements_summary_evictedと同じです。

パラメータ設定

明細書の要約を制御するために、以下のシステム変数が使用されます。

  • tidb_enable_stmt_summary : 明細サマリー機能を有効にするかどうかを決定します。 1はenableを表し、 0はdisableを意味します。この機能はデフォルトで有効になっています。この機能が無効になっている場合、システム テーブルの統計情報はクリアされます。統計情報は、次回この機能が有効になったときに再計算されます。テストの結果、この機能を有効にしてもパフォーマンスへの影響はほとんどないことがわかっています。

  • tidb_stmt_summary_refresh_interval : statements_summaryテーブルが更新される間隔。時間の単位は秒 (s) です。デフォルト値は1800です。

  • tidb_stmt_summary_history_size : statements_summary_historyテーブルに格納される各 SQL ステートメントカテゴリのサイズ。これはstatements_summary_evictedテーブルの最大レコード数でもあります。デフォルト値は24です。

  • tidb_stmt_summary_max_stmt_count : statements_summaryテーブルとstatements_summary_historyテーブルがメモリに格納できる SQL ダイジェストの総数を制限します。デフォルト値は3000です。

    この制限を超えると、TiDB はstatements_summaryテーブルとstatements_summary_historyテーブルの両方から、最も使用頻度の低い SQL ダイジェストを削除します。削除されたダイジェストは、 statements_summary_evictedテーブルにカウントされます。

    注記：

    • SQLダイジェストが削除されると、関連するすべての時間範囲のサマリーデータがstatements_summaryテーブルとstatements_summary_historyテーブルの両方から削除されます。その結果、特定の時間範囲内のSQLダイジェストの数が制限を超えない場合でも、 statements_summary_historyテーブルのSQLダイジェストの数が実際のSQLダイジェストの数よりも少なくなる可能性があります。このような状況が発生し、パフォーマンスに影響する場合は、 tidb_stmt_summary_max_stmt_countの値を増やすことをお勧めします。
    • TiDB Self-Managed の場合、 tidb_stmt_summary_enable_persistentが有効になっていると、 statements_summary_historyテーブルのデータがディスクに永続化されます。この場合、 tidb_stmt_summary_max_stmt_count statements_summaryテーブルがメモリに格納できる SQL ダイジェストの数のみを制限し、 statements_summary -E}} を超えると、TiDB はtidb_stmt_summary_max_stmt_countのみを削除します。

  • tidb_stmt_summary_max_sql_length : DIGEST_TEXTとQUERY_SAMPLE_TEXTの最長表示長を指定します。デフォルト値は4096です。

  • tidb_stmt_summary_internal_query : TiDB SQLステートメントをカウントするかどうかを決定します。 1はカウントすることを意味し、 0カウントしないことを意味します。デフォルト値は0です。

ステートメントサマリーの設定例を以下に示します。

set global tidb_stmt_summary_max_stmt_count = 3000;
set global tidb_enable_stmt_summary = true;
set global tidb_stmt_summary_refresh_interval = 1800;
set global tidb_stmt_summary_history_size = 24;

前述の設定が有効になると、 statements_summaryテーブルは 30 分ごとにクリアされ、 statements_summary_historyテーブルには最大 3000 種類の SQL ステートメントが格納されます。各タイプについて、 statements_summary_historyテーブルには直近 24 期間のデータが格納されます。 statements_summary_evictedテーブルには、ステートメント サマリーから SQL ステートメントが削除された直近 24 期間が記録されます。 statements_summary_evictedテーブルは 30 分ごとに更新されます。

注記：

  • SQL タイプが毎分出現する場合、 statements_summary_historyには直近 12 時間分のデータが格納されます。SQL タイプが毎日 00:00 から 00:30 の間にのみ出現する場合、 statements_summary_historyには直近 24 期間分のデータが格納されます。各期間は 1 日です。したがって、 statements_summary_historyにはこの SQL タイプに関する直近 24 日分のデータが格納されます。
  • tidb_stmt_summary_history_size 、 tidb_stmt_summary_max_stmt_count 、およびtidb_stmt_summary_max_sql_length構成項目はメモリ使用量に影響します。これらの構成は、ニーズ、SQLサイズ、SQL数、およびマシン構成に基づいて調整することをお勧めします。大きすぎる値を設定することはお勧めしません。メモリ使用量はtidb_stmt_summary_history_size tidb_stmt_summary_max_stmt_count tidb_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カテゴリが削除されることがわかります。この場合、 statement_summaryテーブルのサイズを少なくとも59レコード増やすことをお勧めします。つまり、サイズを少なくとも3059レコードまで増やす必要があります。

制限

デフォルトでは、ステートメントのサマリーテーブルはメモリに保存されます。TiDBサーバーが再起動すると、すべてのデータが失われます。

この問題を解決するため、TiDB v6.6.0では、デフォルトでは無効になっている声明要約の持続性機能を試験的に導入しました。この機能を有効にすると、履歴データはメモリに保存されず、直接ディスクに書き込まれます。これにより、TiDBサーバーが再起動しても履歴データは保持されます。

持続ステートメントの概要

で説明したように、ステートメントサマリーテーブルは制限でメモリに保存されます。TiDBサーバーが再起動すると、すべてのステートメントサマリーが失われます。バージョン6.6.0以降、TiDBはステートメントサマリーの永続化を有効または無効にするための設定項目tidb_stmt_summary_enable_persistent試験的に提供しています。

ステートメントのサマリーを永続化するには、TiDB構成ファイルに次の構成項目を追加します。

[instance]
tidb_stmt_summary_enable_persistent = true
# The following entries use the default values, which can be modified as needed.
# tidb_stmt_summary_filename = "tidb-statements.log"
# tidb_stmt_summary_file_max_days = 3
# tidb_stmt_summary_file_max_size = 64 # MiB
# tidb_stmt_summary_file_max_backups = 0

ステートメントサマリーの永続化が有効になると、メモリには現在のリアルタイムデータのみが保持され、履歴データは保持されません。リアルタイムデータが履歴データとして更新されると、履歴データは、パラメータ設定セクションで説明されているtidb_stmt_summary_refresh_interval間隔でディスクに書き込まれます。 statements_summary_historyテーブルまたはcluster_statements_summary_historyテーブルに対するクエリは、メモリ内データとディスク上のデータを組み合わせた結果を返します。

注記：

  • ステートメントサマリーの永続化が有効になっている場合、メモリが履歴データを保持しないため、パラメータ設定セクションで説明されているtidb_stmt_summary_history_size構成は無効になります。代わりに、永続化のための履歴データの保持期間とサイズを制御するために、次の 3 つの構成が使用されますtidb_stmt_summary_file_max_days 、 tidb_stmt_summary_file_max_size 、およびtidb_stmt_summary_file_max_backups 。
  • tidb_stmt_summary_refresh_intervalの値が小さいほど、ディスクに書き込まれるデータ量は多くなります。しかし、これは同時に、ディスクに書き込まれる冗長なデータ量も多くなることを意味します。

トラブルシューティングの例

このセクションでは、ステートメントサマリー機能を使用して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文が最も長い処理時間を要しますか？

10:00から10:30にかけてQPSが大幅に低下した場合、履歴テーブルから処理時間が最も長い3つのSQLステートメントのカテゴリを特定できます。

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 ステートメントの以前の実行がプラン キャッシュにヒットしたかどうかを示します。
  • PLAN_CACHE_UNQUALIFIED : このカテゴリの SQL ステートメントがプラン キャッシュにヒットしなかった回数。
  • PLAN_CACHE_UNQUALIFIED_LAST_REASON : このカテゴリの 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 : 使用される最大ディスク容量 (バイト)。
  • AVG_TIDB_CPU_TIME : このカテゴリの SQL ステートメントが消費する TiDBサーバーのCPU 時間の平均値。Top Top SQL機能が有効になっている場合にのみ意味のある値が表示されます。それ以外の場合は、値は常に0になります。

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_TIKV_CPU_TIME : このカテゴリの SQL ステートメントが消費する TiKVサーバーのCPU 時間の平均値。

取引関連フィールド：

  • 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でグループ化されます。つまり、 COMMITが異なるprev_sample_textステートメントは、異なる行にグループ化されます。現在の SQL ステートメントがCOMMITでない場合、 PREV_SAMPLE_TEXTフィールドは空の文字列になります。

リソース制御に関連する分野：

  • AVG_REQUEST_UNIT_WRITE : SQL ステートメントによって消費される書き込み RU の平均数。
  • MAX_REQUEST_UNIT_WRITE : SQL ステートメントによって消費される書き込み RU の最大数。
  • AVG_REQUEST_UNIT_READ : SQL ステートメントによって消費される読み取り RU の平均数。
  • MAX_REQUEST_UNIT_READ : SQL ステートメントによって消費される読み取り RU の最大数。
  • AVG_QUEUED_RC_TIME : SQL ステートメントを実行する際に、利用可能な RU を待つ平均時間。
  • MAX_QUEUED_RC_TIME : SQL ステートメントを実行する際に、使用可能な RU の最大待機時間。
  • RESOURCE_GROUP : SQL ステートメントにバインドされたリソース グループ。

storageエンジンに関連する分野：

  • STORAGE_KV : v8.5.5 で導入され、このカテゴリの SQL ステートメントの以前の実行が TiKV からデータを読み取ったかどうかを示します。
  • STORAGE_MPP : v8.5.5 で導入され、このカテゴリの SQL ステートメントの以前の実行がTiFlashからデータを読み取ったかどうかを示します。

statements_summary_evictedフィールドの説明

  • BEGIN_TIME : 開始時刻を記録します。
  • END_TIME : 終了時刻を記録します。
  • EVICTED_COUNT : 記録期間中に排除された SQL カテゴリの数。

このページは役に立ちましたか？