TiDB 慢查询日志分析
作者: longzhuquan 原文来源:https://tidb.net/blog/90e27aa0
背景
TiDB 中的慢查询日志是一项关键的性能监控工具,其主要作用在于协助数据库管理员追踪执行时间较长的 SQL 查询语句。通过记录那些超过设定阈值的查询,慢查询日志为性能优化提供了关键的线索,有助于发现潜在的性能瓶颈,优化索引以及重构查询语句,从而提升数据库的整体性能。本文主要介绍了 TiDB 中慢查询日志的功能,并探讨了常用的慢查询日志分析方法。
慢查询相关参数
tidb_enable_slow_log
:用于控制是否开启 slow log 功能。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
。
慢查询日志原理
TiDB 的慢查询日志原理与 Mysql 一致,在每条 SQL 执行结束时,并且执行时间超过慢日志阈值时,会把 SQL 执行相关信息记录到慢日志中,同样的 SQL 多次执行超过阈值都会记录。
分析慢查询日志
由于 TiDB 采用存算分离架构的分布式数据库,在这种架构下,每个 TiDB Server 节点都会产生慢日志。为方便查询慢日志,TiDB 提供了内存映射表 INFORMATION_SCHEMA.SLOW_QUERY
,并在 TiDB Dashboard 中提供了专门的界面用于搜索和查看慢查询日志。官方文档中也提供了多种常见的慢查询日志查询语句,参考:慢查询日志 。
然而,在系统高负载或异常情况下,短时间内生成过多慢 SQL 导致慢 SQL 变得难以分析,这也是像 MySQL 等数据库提供慢日志分析工具的原因,例如 mysqldumpslow
、pt-query-digest
等工具。这些工具通常以某种聚合的方式输出结果,使结果更加清晰易懂。借鉴这些工具的思路,笔者开发了一条常用的慢日志分析 SQL,以更便捷地处理慢查询日志。
慢日志聚合查询 SQL
这个 SQL 是笔者常用的一条查询语句,大家可以根据个人需要灵活地调整排序字段、查询字段和查询条件,以满足不同场景下的分析需求。
在这个 SQL 中,query 和 plan 字段是使用标量子查询的方式获取。经过测试,这种写法相比直接使用 group by,能够节省大量内存,所以能够分析更长时间段的慢查询。
既然是聚合查询,为什么不直接用statements_summary_history
表呢?笔者觉得有三点原因,一是statements_summary_history
由于本身是半小时的聚合数据,在应对短时间段的性能分析时可能不够精细。二是早期版本的statements_summary_history
是纯内存表,可能由于 TiDB Server OOM 重启而导致数据丢失,而慢查询日志是存储在文件中的,因此 TiDB Server OOM 重启不会导致慢查询日志丢失。三是statements_summary_history
有容量限制,记录的 SQL 可能被驱逐出去,而慢查询日志默认记录超过 300 毫秒的查询,已满足分析需求了。
单条 SQL 执行历史
这条 SQL 查询语句是笔者常用的工具,用于分析单个 SQL 的历史执行情况。通过这个查询,可以清晰地了解特定 SQL 在历次执行中的变化,包括执行计划、扫描数据量、执行时间等方面的情况。
收集慢查询日志脚本
这个脚本用于生成 HTML 格式的慢日志分析结果,结合定时任务和 Nginx 的自动索引功能,可以轻松地收集和查看各个 TiDB 集群的慢日志。
脚本请在这个链接取:https://asktug.com/t/topic/1022684
效果展示:
总结
本文阐述了 TiDB 慢查询日志的相关配置和原理,并分享了笔者在实际工作中使用的慢查询日志分析 SQL。为读者提供了一种实际而有效的慢查询日志分析思路。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/47932313a681c85897eb18aab】。文章转载请联系作者。
评论