明細書要約表

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はありません) で提供します。

statements_summary
statements_summary_history
cluster_statements_summary
cluster_statements_summary_history
statements_summary_evicted

注記：
上記のテーブルは、クラスターTiDB CloudスターターおよびTiDB Cloudエッセンシャルでは使用できません。

このドキュメントでは、これらのテーブルについて詳しく説明し、それらを使用して 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 ダイジェストを削除します。

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

診断ページの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タイプが毎日00:00から00:30までしか出現しない場合、 statements_summary_history直近24期間分のデータを保存します（各期間は1日）。したがって、 statements_summary_history直近24日間分のSQLタイプを保存します。
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 Self-Managed にのみ適用されます。TiDB TiDB Cloudの場合、 tidb_stmt_summary_enable_persistentパラメータの値はデフォルトでfalse設定されており、動的な変更はサポートされません。

警告

ステートメントサマリーの永続化は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで問題報告を行ってください。

セクション制限で説明したように、ステートメントサマリーテーブルはデフォルトでメモリに保存されます。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でディスクに書き込まれます。5またはstatements_summary_history cluster_statements_summary_historyテーブルに対するクエリは、メモリ内データとディスク上のデータの両方を組み合わせた結果を返します。

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

このセクションでは、ステートメントサマリー機能を使用して 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 ステートメントの前回の実行がプランキャッシュにヒットしたかどうかを示します。
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 :コプロセッサーが処理したキーの平均数。2 と比較すると、 avg_total_keys avg_processed_keys古いバージョンの MVCC は含まれていません。6 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によってグループ化されます。つまり、 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 カテゴリの数。

明細書要約表

statements_summary

statements_summary_history

statements_summary_evicted

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