TiDB-慢查询日志

慢查询日志

控制慢查询日志相关参数

• 在性能测试中可以关闭自动收集算子的执行信息

  • 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; 

TiDB-慢查询日志

原文：https://www.cnblogs.com/binliubiao/p/14393233.html