📣
TiDB Cloud Serverless が
Starter
に変わりました！このページは自動翻訳されたものです。
原文はこちらからご覧ください。
TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

明細書概要表

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

したがって、v4.0.0-rc.1 以降、TiDB は機能面でevents_statements_summary_by_digestに類似したシステム テーブルをinformation_schema ( performance_schemaはありません) で提供します。

注記：

上記のテーブルはTiDB Cloud Serverlessクラスターでは使用できません。

このドキュメントでは、これらのテーブルについて詳しく説明し、それらを使用して SQL パフォーマンスの問題をトラブルシューティングする方法を紹介します。

statements_summary

statements_summaryはinformation_schemaのシステム テーブルです。4 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文が異なるカテゴリにグループ化されることがあります。同じカテゴリの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と同一です。5 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 ダイジェストの数のみを制限し、 tidb_stmt_summary_max_stmt_count超えた場合にのみ、TiDB はstatements_summaryテーブルから最も使用頻度の低い SQL ダイジェストを削除します。

statements_summary_evictedテーブルは、エビクションが発生した期間と、その期間中にエビクションされた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のデータを表示します。4 cluster_statements_summary_history各 TiDBサーバーのstatements_summary_historyデータを表示します。8 cluster_statements_summary_evicted各 TiDBサーバーのstatements_summary_evictedのデータを表示します。これらのテーブルでは、 INSTANCEフィールドを使用して TiDBサーバーのアドレスを表します。その他のフィールドはstatements_summary 、 statements_summary_history 、 statements_summary_evictedと同じです。

パラメータ設定

ステートメント サマリーを制御するために、次のシステム変数が使用されます。

  • tidb_enable_stmt_summary : ステートメントサマリー機能を有効にするかどうかを決定します。2 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セルフマネージドの場合、 tidb_stmt_summary_enable_persistent有効になっていると、 statements_summary_historyテーブルのデータがディスクに永続化されます。この場合、 tidb_stmt_summary_max_stmt_countはstatements_summaryテーブルがメモリに保存できるSQLダイジェストの数のみを制限し、 tidb_stmt_summary_max_stmt_countを超えた場合にのみ、TiDBはstatements_summaryテーブルから最も使用頻度の低いSQLダイジェストを削除します。

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

  • tidb_stmt_summary_internal_query : TiDB SQL文をカウントするかどうかを決定します。2 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タイプが毎日0:00から0:30までしか出現しない場合、 statements_summary_history直近24期間分のデータを保存します（各期間は1日）。したがって、 statements_summary_history直近24日間分のデータを保存します。
  • tidb_stmt_summary_history_size tidb_stmt_summary_max_stmt_count設定項目はメモリ使用量に影響します。これらの設定は、ニーズ、SQLサイズ、SQL数、マシン構成に応じて調整することをお勧めします。あまり大きな値に設定することtidb_stmt_summary_max_sql_lengthお勧めしません。メモリ使用量は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サーバーを再起動すると、すべてのステートメントサマリーが失われます。v6.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_file_max_backups tidb_stmt_summary_history_size設定は適用されなくなります。代わりに、 tidb_stmt_summary_file_max_days tidb_stmt_summary_file_max_size 3つの設定を使用して、永続化のための履歴データの保持期間とサイズを制御します。
  • 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 が大幅に減少した場合、履歴テーブルから、最も時間のかかる 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 :コプロセッサーが処理したキーの平均数。2 と比較すると、 avg_total_keys avg_processed_keys古いバージョンの MVCC は含まれていません。6 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フィールドは空文字列になります。

リソース制御に関連するフィールド:

  • 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 ステートメントにバインドされたリソース グループ。

statements_summary_evictedフィールドの説明

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

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