TiDB-慢查詢日志

慢查詢日志

控制慢查詢日志相關參數

變量名稱	說明
tidb_slow_log_threshold	設置慢日志的閾值，將執行時間超過閾值的 SQL 語句記錄到慢日志中。默認值是 300 ms。
tidb_query_log_max_len	設置慢日志記錄 SQL 語句的最大長度。默認值是 4096 byte。
tidb_redact_log	設置慢日志記錄 SQL 時是否將用戶數據脫敏用 ? 代替。默認值是 0 ，即關閉該功能。
tidb_enable_collect_execution_info	設置是否記錄執行計划中各個算子的物理執行信息，默認值是 1。該功能對性能的影響約為 3%。

• 在性能測試中可以關閉自動收集算子的執行信息

  • set @@tidb_enable_collect_execution_info=0;
    

查看系統變量的配置值

--  查詢慢日志記錄的SQL最大長度
show variables like 'tidb_query_log_max_len';
select @@tidb_query_log_max_len;
show config where type = 'tidb' and name = 'log.query-log-max-len';

慢查詢日志參數配置

TiDB 將執行時間超過slow-threshold（默認300毫秒）的語句輸出到slow-query-file指定的文件中。

mysql> show config where type='tidb' and name like '%slow%';
+------+---------------------+-----------------------------+-------------------------+
| Type | Instance            | Name                        | Value                   |
+------+---------------------+-----------------------------+-------------------------+
| tidb | 192.168.10.181:4000 | log.enable-slow-log         | true                    |
| tidb | 192.168.10.181:4000 | log.record-plan-in-slow-log | 1                       |
| tidb | 192.168.10.181:4000 | log.slow-query-file         | log/tidb_slow_query.log |
| tidb | 192.168.10.181:4000 | log.slow-threshold          | 300                     |
+------+---------------------+-----------------------------+-------------------------+
4 rows in set, 1 warning (0.01 sec)

mysql> 

TiDB 默認啟用慢查詢日志，可以修改配置 enable-slow-log 來啟用或禁用它。

查看慢查詢日志記錄

通過 slow-query-file 變量中的文件

more /tidb/app/tidb-deploy/log/tidb_slow_query.log

# Time: 2021-01-12T08:51:51.284088475+08:00
# Txn_start_ts: 422160029355868163
# Query_time: 1.59885583
# Parse_time: 0.000342042
# Compile_time: 0.015516221
# Rewrite_time: 0.010854793
# Cop_time: 1.574503392 Process_time: 0.002 Wait_time: 0.003 Backoff_time: 1.51 Request_count: 1 Total_keys: 1
# Index_names: [bind_info:time_index]
# Is_internal: true
# Digest: fc950a72d4169f9e74f5e6a8e8aa06c30838aaaf55fdc67538bf14b69ddfb000
# Stats: bind_info:pseudo
# Num_cop_tasks: 1
# Cop_proc_avg: 0.002 Cop_proc_addr: 192.168.10.181:20160
# Cop_wait_avg: 0.003 Cop_wait_addr: 192.168.10.181:20160
# Cop_backoff_regionMiss_total_times: 10 Cop_backoff_regionMiss_total_time: 1.51
# Mem_max: 35400
# Prepared: false
# Plan_from_cache: false
# Has_more_results: false
# KV_total: 0.04573883
# PD_total: 0.007358997
# Backoff_total: 1.51
# Write_sql_response_total: 0
# Succ: true
# Plan: tidb_decode_plan('XXXXXXXXX')
# Plan_digest: bf4e638d559f82b64926f2b78be0c1d7ea7e7b8728a7e755cb60cd402a23d23e
select original_sql, bind_sql, default_db, status, create_time, update_time, charset, collation, source from mysql.bind_info order by update_time;

字段說明

慢查詢日志中所有時間相關字段的單位都是 “秒”

Slow Query 基礎信息：

• Time：表示日志打印時間。
• Query_time：表示執行這個語句花費的時間。
• Parse_time：表示這個語句在語法解析階段花費的時間。
• Compile_time：表示這個語句在查詢優化階段花費的時間。
• Query：表示 SQL 語句。慢日志里面不會打印 Query，但映射到內存表后，對應的字段叫 Query。
• Digest：表示 SQL 語句的指紋。
• Txn_start_ts：表示事務的開始時間戳，也是事務的唯一 ID，可以用這個值在 TiDB 日志中查找事務相關的其他日志。
• Is_internal：表示是否為 TiDB 內部的 SQL 語句。true 表示 TiDB 系統內部執行的 SQL 語句，false 表示用戶執行的 SQL 語句。
• Index_ids：表示語句涉及到的索引的 ID。
• Succ：表示語句是否執行成功。
• Backoff_time：表示語句遇到需要重試的錯誤時在重試前等待的時間，常見的需要重試的錯誤有以下幾種：遇到了 lock、Region 分裂、tikv server is busy。
• Plan：表示語句的執行計划，用 select tidb_decode_plan('xxx...') SQL 語句可以解析出具體的執行計划。
• Prepared：表示這個語句是否是 Prepare 或 Execute 的請求。
• Plan_from_cache：表示這個語句是否命中了執行計划緩存。
• Rewrite_time：表示這個語句在查詢改寫階段花費的時間。
• Preproc_subqueries：表示這個語句中被提前執行的子查詢個數，如 where id in (select if from t) 這個子查詢就可能被提前執行。
• Preproc_subqueries_time：表示這個語句中被提前執行的子查詢耗時。
• Exec_retry_count：表示這個語句執行的重試次數。一般出現在悲觀事務中，上鎖失敗時重試執行該語句。
• Exec_retry_time：表示這個語句的重試執行時間。例如某個查詢一共執行了三次（前兩次失敗），則 Exec_retry_time 表示前兩次的執行時間之和，Query_time 減去 Exec_retry_time 則為最后一次執行時間。

和事務執行相關的字段：

• Prewrite_time：表示事務兩階段提交中第一階段（prewrite 階段）的耗時。
• Commit_time：表示事務兩階段提交中第二階段（commit 階段）的耗時。
• Get_commit_ts_time：表示事務兩階段提交中第二階段（commit 階段）獲取 commit 時間戳的耗時。
• Local_latch_wait_time：表示事務兩階段提交中第二階段（commit 階段）發起前在 TiDB 側等鎖的耗時。
• Write_keys：表示該事務向 TiKV 的 Write CF 寫入 Key 的數量。
• Write_size：表示事務提交時寫 key 或 value 的總大小。
• Prewrite_region：表示事務兩階段提交中第一階段（prewrite 階段）涉及的 TiKV Region 數量。每個 Region 會觸發一次遠程過程調用。

和內存使用相關的字段：

• Mem_max：表示執行期間 TiDB 使用的最大內存空間，單位為 byte。

和硬盤使用相關的字段：

• Disk_max: 表示執行期間 TiDB 使用的最大硬盤空間，單位為 byte。

和 SQL 執行的用戶相關的字段：

• User：表示執行語句的用戶名。
• Conn_ID：表示用戶的鏈接 ID，可以用類似 con:3 的關鍵字在 TiDB 日志中查找該鏈接相關的其他日志。
• DB：表示執行語句時使用的 database。

和 TiKV Coprocessor Task 相關的字段：

• Request_count：表示這個語句發送的 Coprocessor 請求的數量。
• Total_keys：表示 Coprocessor 掃過的 key 的數量。
• Process_time：執行 SQL 在 TiKV 的處理時間之和，因為數據會並行的發到 TiKV 執行，這個值可能會超過 Query_time。
• Wait_time：表示這個語句在 TiKV 的等待時間之和，因為 TiKV 的 Coprocessor 線程數是有限的，當所有的 Coprocessor 線程都在工作的時候，請求會排隊；當隊列中有某些請求耗時很長的時候，后面的請求的等待時間都會增加。
• Process_keys：表示 Coprocessor 處理的 key 的數量。相比 total_keys，processed_keys 不包含 MVCC 的舊版本。如果 processed_keys 和 total_keys 相差很大，說明舊版本比較多。
• Cop_proc_avg：cop-task 的平均執行時間。
• Cop_proc_p90：cop-task 的 P90 分位執行時間。
• Cop_proc_max：cop-task 的最大執行時間。
• Cop_proc_addr：執行時間最長的 cop-task 所在地址。
• Cop_wait_avg：cop-task 的平均等待時間。
• Cop_wait_p90：cop-task 的 P90 分位等待時間。
• Cop_wait_max：cop-task 的最大等待時間。
• Cop_wait_addr：等待時間最長的 cop-task 所在地址。
• Cop_backoff_{backoff-type}_total_times：因某種錯誤造成的 backoff 總次數。
• Cop_backoff_{backoff-type}_total_time：因某種錯誤造成的 backoff 總時間。
• Cop_backoff_{backoff-type}_max_time：因某種錯誤造成的最大 backoff 時間。
• Cop_backoff_{backoff-type}_max_addr：因某種錯誤造成的最大 backoff 時間的 cop-task 地址。
• Cop_backoff_{backoff-type}_avg_time：因某種錯誤造成的平均 backoff 時間。
• Cop_backoff_{backoff-type}_p90_time：因某種錯誤造成的 P90 分位 backoff 時間。

使用系統表查看

通過查詢 INFORMATION_SCHEMA.SLOW_QUERY 表來查詢慢查詢日志中的內容，表中列名和慢日志中字段名一一對應。每次查詢 SLOW_QUERY 表時，TiDB 都會去讀取和解析一次當前的慢查詢日志。 在TiDB 4.0 中新增了 CLUSTER_SLOW_QUERY 系統表，用來查詢所有 TiDB 節點的慢查詢信息。

使用示例

當前 TiDB 已寫入慢日志文件的慢查詢數據

select count(*),
       min(time),
       max(time)
from information_schema.slow_query;

指定查詢時間范圍的慢查詢數據

select count(*),
       min(time),
       max(time)
from information_schema.slow_query
where time > '2021-01-12 00:00:00'
  and time < '2021-01-13 00:00:00';

SELECT * FROM
    (SELECT /*+ AGG_TO_COP(), HASH_AGG() */ count(*),
         min(time),
         sum(query_time) AS sum_query_time,
         sum(Process_time) AS sum_process_time,
         sum(Wait_time) AS sum_wait_time,
         sum(Commit_time),
         sum(Request_count),
         sum(process_keys),
         sum(Write_keys),
         max(Cop_proc_max),
         min(query),min(prev_stmt),
         digest
    FROM information_schema.CLUSTER_SLOW_QUERY
    WHERE time >= '2021-01-12 09:00:00'
            AND time < '2021-01-12 10:00:00'
            AND Is_internal = false
    GROUP BY  digest) AS t1
WHERE t1.digest NOT IN
    (SELECT /*+ AGG_TO_COP(), HASH_AGG() */ digest
    FROM information_schema.CLUSTER_SLOW_QUERY
    WHERE time >= '2021-01-12 09:00:00'
            AND time < '2021-01-12 10:00:00'
    GROUP BY  digest)
ORDER BY  t1.sum_query_time DESC limit 10\G

搜索 Top N 的慢查詢

-- is_internal=false 表示排除 TiDB 內部的慢查詢，只看用戶的慢查詢
select query_time, query
from information_schema.slow_query
where is_internal = false  -- 排除 TiDB 內部的慢查詢 SQL
order by query_time desc
limit 2;

搜索統計信息為 pseudo 的慢查詢 SQL 語句

統計信息為 pseudo : 表示可能因為沒有統計信息，或者統計信息過舊，不會用統計信息來進行估算。

select query, query_time, stats
from information_schema.slow_query
where is_internal = false
  and stats like '%pseudo%';
-- 
select instance, query, query_time, stats
from information_schema.cluster_slow_query
where is_internal = false
  and stats like '%pseudo%';

查詢執行計划發生變化的慢查詢

select count(distinct plan_digest) as count,
       digest,
       min(query)
from information_schema.cluster_slow_query
group by digest
having count > 1
limit 3\G

查詢集群各個 TIDB 節點的慢查詢數量

select instance, count(*) from information_schema.cluster_slow_query 
where time >= "2021-01-12 00:00:00" 
and time < now() 
group by instance;

用 pt-query-digest 工具分析慢日志

建議使用 pt-query-digest 3.0.13 及以上版本。

定位慢查詢語句

admin show slow 命令

通過 admin show slow SQL 命令定位慢查詢，默認只返回用戶 SQL 中的慢查詢記錄。

recent N

-- 顯示最近的 N 條慢查詢記錄
admin show slow recent N;

-- 如：顯示最近的 10 條慢查詢記錄
admin show slow recent 10;

top N

-- top N 則顯示最近一段時間（大約幾天）內，最慢的查詢記錄
admin show slow top [internal | all] N;
-- 指定 internal 選項，則返回查詢系統內部 SQL 的慢查詢記錄
-- 指定 all 選項，返回系統內部和用戶 SQL 匯總以后的慢查詢記錄

示例

admin show slow top 3;
admin show slow top internal 3;
admin show slow top all 5;

注意：

由於內存限制，保留的慢查詢記錄的條數是有限的。當命令查詢的 N 大於記錄條數時，返回的結果記錄條數會小於 N。

分析慢查詢

TiDB 處理查詢過程的關鍵階段如下圖：

分析過程

1. 定位查詢瓶頸：即查詢過程中耗時多的部分
2. 分析系統性問題：根據瓶頸點，結合當時的監控/日志等信息，分析可能的原因
3. 分析優化器問題：分析是否有更好的執行計划

定位瓶頸

獲取耗時信息的途徑

• 慢查詢日志（可以使用 http://PD-IP:2379/dashboard/#/slow_query）
  • 慢日志記錄了 SQL 從解析到返回，幾乎所有階段的耗時
• explain analyze 語句
  • SQL 實際執行中每個執行算子的耗時，對執行耗時有更細分的統計

資源消耗多SQL

(Expensive query) 資源消耗高SQL

TiDB 會將執行時間超過 tidb_expensive_query_time_threshold 限制（默認值為 60s），或使用內存超過 mem-quota-query 限制（默認值為 1 GB）的語句輸出到 tidb-server 日志文件（默認文件為 “tidb.log”）中。用於在語句執行結束前定位消耗系統資源多的查詢語句（以下簡稱為 expensive query），幫助分析和解決語句執行的性能問題。

注意：expensive query 日志和慢查詢日志的區別是，慢查詢日志是在語句執行完后才打印，而 expensive query 日志可以將正在執行的語句的相關信息打印出來。當一條語句在執行過程中達到資源使用閾值時（執行時間/使用內存量），TiDB 會即時將這條語句的相關信息寫入日志。

(Expensive query) 資源消耗高SQL的日志示例

[WARN] [expensivequery.go:167] [expensive_query] [cost_time=60.008338935s] [wait_time=0s] [request_count=1] [total_keys=70] [process_keys=65] [num_cop_tasks=1] [process_avg_time=0s] [process_p90_time=0s] [process_max_time=0s] [process_max_addr=10.0.1.9:20160] [wait_avg_time=0.002s] [wait_p90_time=0.002s] [wait_max_time=0.002s] [wait_max_addr=10.0.1.9:20160] [stats=t:pseudo] [conn_id=60026] [user=root] [database=test] [table_ids="[122]"] [txn_start_ts=414420273735139329] [mem_max="1035 Bytes (1.0107421875 KB)"] [sql="insert into t select sleep(1) from t"]

日志輸出字段說明

基本字段：

• cost_time：日志打印時語句已經花費的執行時間。
• stats：語句涉及到的表或索引使用的統計信息版本。值為 pesudo 時表示無可用統計信息，需要對表或索引進行 analyze。
• table_ids：語句涉及到的表的 ID。
• txn_start_ts：事務的開始時間戳，也是事務的唯一 ID，可以用這個值在 TiDB 日志中查找事務相關的其他日志。
• sql：SQL 語句。

和內存使用相關的字段：

• mem_max：日志打印時語句已經使用的內存空間。該項使用兩種單位標識內存使用量，分別為 Bytes 以及易於閱讀的自適應單位（比如 MB、GB 等）。

和 SQL 執行的用戶相關的字段：

• user：執行語句的用戶名。
• conn_id：用戶的連接 ID，可以用類似 con:60026 的關鍵字在 TiDB 日志中查找該連接相關的其他日志。
• database：執行語句時使用的 database。

和 TiKV Coprocessor Task 相關的字段：

• wait_time：該語句在 TiKV 的等待時間之和，因為 TiKV 的 Coprocessor 線程數是有限的，當所有的 Coprocessor 線程都在工作的時候，請求會排隊；當隊列中有某些請求耗時很長的時候，后面的請求的等待時間都會增加。
• request_count：該語句發送的 Coprocessor 請求的數量。
• total_keys：Coprocessor 掃過的 key 的數量。
• processed_keys：Coprocessor 處理的 key 的數量。與 total_keys 相比，processed_keys 不包含 MVCC 的舊版本。如果 processed_keys 和 total_keys 相差很大，說明舊版本比較多。
• num_cop_tasks：該語句發送的 Coprocessor 請求的數量。
• process_avg_time：Coprocessor 執行 task 的平均執行時間。
• process_p90_time：Coprocessor 執行 task 的 P90 分位執行時間。
• process_max_time：Coprocessor 執行 task 的最長執行時間。
• process_max_addr：task 執行時間最長的 Coprocessor 所在地址。
• wait_avg_time：Coprocessor 上 task 的等待時間。
• wait_p90_time：Coprocessor 上 task 的 P90 分位等待時間。
• wait_max_time：Coprocessor 上 task 的最長等待時間。
• wait_max_addr：task 等待時間最長的 Coprocessor 所在地址。

排查SQL性能問題

從TiDB 4.0開始，在 information_schema 中提供了用於監控和統計 SQL 的系統表，幫助分析定位SQL的性能問題。

系統表名稱

僅顯示單台 TiDB server 的 statement summary 數據

• statements_summary ： 把 SQL 按 SQL digest 和 plan digest 分組，統計每一組的 SQL 信息。
  • 它用於保存 SQL 監控指標聚合后的結果。時間單位是納秒 (ns)
  • 為了監控指標的即時性，statements_summary 里的數據定期被清空，只展現最近一段時間內的聚合結果。清空周期由系統變量 tidb_stmt_summary_refresh_interval 設置。
• statements_summary_history ： 與 statements_summary 完全相同的表結構，用於保存歷史時間段的數據。

查詢整個集群的 statement summary 數據

• cluster_statements_summary : 顯示各台 TiDB server 的 statements_summary 數據
• cluster_statements_summary_history : 顯示各台 TiDB server 的 statements_summary_history 數據

上面2個集群系統表使用用字段 INSTANCE 表示 TiDB server 的地址。

注意：重啟TiDB后，上面的4張系統表的數據會清空。因為它們是內存表，不會持久化數據。

系統表字段說明

SQL 的基礎信息：

• STMT_TYPE：SQL 語句的類型
• SCHEMA_NAME：執行這類 SQL 的當前 schema
• DIGEST：這類 SQL 的 digest
• DIGEST_TEXT：規一化后的 SQL
• QUERY_SAMPLE_TEXT：這類 SQL 的原 SQL 語句，多條語句只取其中一條
• TABLE_NAMES：SQL 中涉及的所有表，多張表用 , 分隔
• INDEX_NAMES：SQL 中使用的索引名，多個索引用 , 分隔
• SAMPLE_USER：執行這類 SQL 的用戶名，多個用戶名只取其中一個
• PLAN_DIGEST：執行計划的 digest
• PLAN：原執行計划，多條語句只取其中一條的執行計划
• PLAN_CACHE_HITS：這類 SQL 語句命中 plan cache 的總次數
• PLAN_IN_CACHE：這類 SQL 語句的上次執行是否命中了 plan cache

執行時間相關的信息：

• SUMMARY_BEGIN_TIME：當前統計的時間段的開始時間
• SUMMARY_END_TIME：當前統計的時間段的結束時間
• FIRST_SEEN：這類 SQL 的首次出現時間
• LAST_SEEN：這類 SQL 的最后一次出現時間

在 TiDB server 上的執行數據：

• EXEC_COUNT：這類 SQL 的總執行次數
• SUM_ERRORS：執行過程中遇到的 error 的總數
• SUM_WARNINGS：執行過程中遇到的 warning 的總數
• 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：使用的平均內存，單位 byte
• MAX_MEM：使用的最大內存，單位 byte
• AVG_DISK：使用的平均硬盤空間，單位 byte
• MAX_DISK：使用的最大硬盤空間，單位 byte

和 TiKV Coprocessor Task 相關的字段：

• SUM_COP_TASK_NUM：發送 Coprocessor 請求的總數
• MAX_COP_PROCESS_TIME：cop-task 的最大處理時間
• MAX_COP_PROCESS_ADDRESS：執行時間最長的 cop-task 所在地址
• MAX_COP_WAIT_TIME：cop-task 的最大等待時間
• MAX_COP_WAIT_ADDRESS：等待時間最長的 cop-task 所在地址
• AVG_PROCESS_TIME：SQL 在 TiKV 的平均處理時間
• MAX_PROCESS_TIME：SQL 在 TiKV 的最大處理時間
• AVG_WAIT_TIME：SQL 在 TiKV 的平均等待時間
• MAX_WAIT_TIME：SQL 在 TiKV 的最大等待時間
• AVG_BACKOFF_TIME：SQL 遇到需要重試的錯誤時在重試前的平均等待時間
• MAX_BACKOFF_TIME：SQL 遇到需要重試的錯誤時在重試前的最大等待時間
• AVG_TOTAL_KEYS：Coprocessor 掃過的 key 的平均數量
• MAX_TOTAL_KEYS：Coprocessor 掃過的 key 的最大數量
• AVG_PROCESSED_KEYS：Coprocessor 處理的 key 的平均數量。相比 avg_total_keys，avg_processed_keys 不包含 MVCC 的舊版本。如果 avg_total_keys 和 avg_processed_keys 相差很大，說明舊版本比較多
• MAX_PROCESSED_KEYS：Coprocessor 處理的 key 的最大數量

和事務相關的字段：

• AVG_PREWRITE_TIME：prewrite 階段消耗的平均時間
• MAX_PREWRITE_TIME prewrite 階段消耗的最大時間
• AVG_COMMIT_TIME：commit 階段消耗的平均時間
• MAX_COMMIT_TIME：commit 階段消耗的最大時間
• AVG_GET_COMMIT_TS_TIME：獲取 commit_ts 的平均時間
• MAX_GET_COMMIT_TS_TIME：獲取 commit_ts 的最大時間
• AVG_COMMIT_BACKOFF_TIME：commit 時遇到需要重試的錯誤時在重試前的平均等待時間
• MAX_COMMIT_BACKOFF_TIME：commit 時遇到需要重試的錯誤時在重試前的最大等待時間
• AVG_RESOLVE_LOCK_TIME：解決事務的鎖沖突的平均時間
• MAX_RESOLVE_LOCK_TIME：解決事務的鎖沖突的最大時間
• AVG_LOCAL_LATCH_WAIT_TIME：本地事務等待的平均時間
• MAX_LOCAL_LATCH_WAIT_TIME：本地事務等待的最大時間
• AVG_WRITE_KEYS：寫入 key 的平均數量
• MAX_WRITE_KEYS：寫入 key 的最大數量
• AVG_WRITE_SIZE：寫入的平均數據量，單位 byte
• MAX_WRITE_SIZE：寫入的最大數據量，單位 byte
• AVG_PREWRITE_REGIONS：prewrite 涉及的平均 Region 數量
• MAX_PREWRITE_REGIONS：prewrite 涉及的最大 Region 數量
• AVG_TXN_RETRY：事務平均重試次數
• MAX_TXN_RETRY：事務最大重試次數
• SUM_BACKOFF_TIMES：這類 SQL 遇到需要重試的錯誤后的總重試次數
• BACKOFF_TYPES：遇到需要重試的錯誤時的所有錯誤類型及每種類型重試的次數，格式為 類型:次數。如有多種錯誤則用 , 分隔，例如 txnLock:2,pdRPC:1
• AVG_AFFECTED_ROWS：平均影響行數
• PREV_SAMPLE_TEXT：當 SQL 是 COMMIT 時，該字段為 COMMIT 的前一條語句；否則該字段為空字符串。當 SQL 是 COMMIT 時，按 digest 和 prev_sample_text 一起分組，即不同 prev_sample_text 的 COMMIT 也會分到不同的行

用於控制 statement summary 的系統變量

• tidb_enable_stmt_summary：是否打開 statement summary 功能。1 代表打開，0 代表關閉，默認打開。statement summary 關閉后，系統表里的數據會被清空，下次打開后重新統計。經測試，打開后對性能幾乎沒有影響。
• tidb_stmt_summary_refresh_interval：statements_summary 的清空周期，單位是秒 (s)，默認值是 1800。
• tidb_stmt_summary_history_size：statements_summary_history 保存每種 SQL 的歷史的數量，默認值是 24。
• tidb_stmt_summary_max_stmt_count：statement summary tables 保存的 SQL 種類數量，默認 200 條。當 SQL 種類超過該值時，會移除最近沒有使用的 SQL。
• tidb_stmt_summary_max_sql_length：字段 DIGEST_TEXT 和 QUERY_SAMPLE_TEXT 的最大顯示長度，默認值是 4096。
• tidb_stmt_summary_internal_query：是否統計 TiDB 的內部 SQL。1 代表統計，0 代表不統計，默認不統計。

注意：

tidb_stmt_summary_history_size、tidb_stmt_summary_max_stmt_count、tidb_stmt_summary_max_sql_length 這些配置都影響內存占用，建議根據實際情況調整，不宜設置得過大。

參數的作用域

TiDB 提供了 global 和 session 兩種作用域。

• 設置 global 變量后整個集群立即生效
• 設置 session 變量后當前 TiDB server 立即生效，這對於調試單個 TiDB server 比較有用
• 優先讀 session 變量，沒有設置過 session 變量才會讀 global 變量
• 把 session 變量設為空字符串，將會重新讀 global 變量

參數配置示例

-- 每 30 分鍾清空一次。因為 24 * 30 分鍾 = 12 小時，所以 statements_summary_history 保存最近 12 小時的歷史數據。
set global tidb_enable_stmt_summary = true;
set global tidb_stmt_summary_refresh_interval = 1800;  -- 30 分鍾
set global tidb_stmt_summary_history_size = 24;