CLUSTER_STATEMENTS_SUMMARY_HISTORY记录多长时间的慢日志?

【 TiDB 使用环境】v4,v6
【概述】 查询TOP 20慢sql
【问题】 CLUSTER_STATEMENTS_SUMMARY表按digest记录记录的慢日志,根据官方文档,这个表记录半个小时
超过半个小时的会记录到CLUSTER_STATEMENTS_SUMMARY_HISTORY 历史表,历史表根据参数tidb_stmt_summary_refresh_interval=1800以及tidb_stmt_summary_history_size=24 保存最近12小时的历史数据
可是在CLUSTER_STATEMENTS_SUMMARY 和CLUSTER_STATEMENTS_SUMMARY_HISTORY 两个表都查到

MySQL [information_schema]> select min(SUMMARY_BEGIN_TIME) from CLUSTER_STATEMENTS_SUMMARY;
+-------------------------+
| min(SUMMARY_BEGIN_TIME) |
+-------------------------+
| 2022-05-28 16:30:00     |

 select min(SUMMARY_END_TIME) from CLUSTER_STATEMENTS_SUMMARY;
+-----------------------+
| min(SUMMARY_END_TIME) |
+-----------------------+
| 2022-05-28 17:00:00   |
+-----------------------+
1 row in set (0.004 sec)

这个时间是集群服务开始的时间,哪这两个表不是收集了从 2022-05-28 16:30:00 开始的 慢SQL ?
但是 这2个表的记录数不一样的

1 个赞

tidb_stmt_summary_history_size=24 保存的每种SQL历史数量,我理解是 从集群开始到当前时间保存此种SQL出现的最近24次
并不是官方文档里说的12个小时的历史数据 ,大佬我理解的对不?

这个每种是按digest吗?还是每个SQL?

他的分类是是 sql_digest+plan_digest 相同的 是同一种SQL,因为statements_summary里的记录是按半小时一次的时间统计(SUMMARY_BEGIN_TIME 到 SUMMARY_end_TIME) ,所以到histroy里24个时间段就是12小时。 statements_summary是按条数做清理的, history是按保留的半小时时间段个数来清理的

tidb的这个设计不是特别友好感觉,这方面还是Oracle做的好些,不过tidb的慢日志还是很详细的,记录了执行计划

1 个赞

“到histroy里24个时间段就是12小时”,可是查询的ect min(SUMMARY_BEGIN_TIME) from CLUSTER_STATEMENTS_SUMMARY; 却得到了 SUMMARY_BEGIN_TIME 时间为 集群启动时的 时间,没明白:joy:

如果你的语句少于3000条,这种情况是正常的。因为这个12个小时只是强制保留时间,而不是清理时间。真正的清理超过3000。

1 个赞

明白了,感谢各位大佬:+1:

https://docs.pingcap.com/zh/tidb/stable/statement-summary-tables#statement-summary-tables
找到了原文

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。