重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

ステートメント要約表

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サーバーレスクラスターでは使用できません。

このドキュメントでは、これらのテーブルについて詳しく説明し、それらを使用して 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 ステートメントには同じ実行プランがあります。

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 以降では、リソース管理有効になっているクラスターの場合、 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変数は、 statement_summaryテーブルstatement_summaryメモリに保存するステートメントの最大数を制御します。5 テーブルは LRU アルゴリズムを使用します。SQL ステートメントの数がtidb_stmt_summary_max_stmt_count値を超えると、最も長い未使用レコードがテーブルから削除されます。各期間中に削除された SQL ステートメントの数は、 statements_summary_evictedテーブルに記録されます。

statements_summary_evictedテーブルは、SQL レコードがstatement_summaryテーブルから削除された場合にのみ更新されます。5 statements_summary_evictedには、削除が発生した期間と削除された SQL ステートメントの数のみが記録されます。

ステートメントサマリーの`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 : ステートメントサマリーテーブルに保存できる SQL ステートメントの数を制限します。デフォルト値は3000です。制限を超えると、TiDB は最近使用されていない SQL ステートメントをクリアします。これらのクリアされた SQL ステートメントは、 DIGESTがNULLに設定された行として表され、 statements_summary_evictedテーブルに記録されます。 TiDBダッシュボードのSQLステートメントページでは、これらの行の情報がOthersとして表示されます。

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 はstatement_summary_historyテーブルからすべての時間範囲のその SQL 文カテゴリのデータを削除します。したがって、特定の時間範囲の SQL 文カテゴリの数が制限に達していなくても、 statement_summary_historyテーブルに格納される SQL 文の数は実際の SQL 文の数よりも少なくなります。このような状況が発生してパフォーマンスに影響する場合は、 tidb_stmt_summary_max_stmt_countの値を増やすことをお勧めします。

ステートメントサマリー構成の例を次に示します。

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 ステートメントが格納されます。5 テーブルには、タイプstatements_summary_historyに最近の 24 期間のデータが格納されますstatements_summary_evictedテーブルには、ステートメントサマリーから SQL ステートメントが削除された最近の 24 期間が記録されますstatements_summary_evictedテーブルは 30 分ごとに更新されます。

注記：
SQL タイプが 1 分ごとに表示される場合、 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 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 またはcluster_statements_summary_historyテーブルに対するクエリでは、 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 ステートメントが最も長い合計時間を消費しますか?

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フィールドは空の文字列になります。

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

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テーブル