tidb_stmt_summary_max_stmt_count参数应该怎么设置？

🪐 TiDB 技术问题 性能调优
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】
【遇到的问题】tidb_stmt_summary_max_stmt_count默认3000，发现statements_summary_evicted表一直有移除（最大2300）。改为了6000，还是有移除（最大2120）。官方文档建议是不要有移除， 我是不是可以改为100000这样的较大数，有无影响？官方为什么不默认一个较大的数呢？吧友们都是设置的多少？谢谢
【资源配置】ti-db1机器60G内存，已用27G。ti-db2机器60G内存，已用20G。
【附件：截图/日志/监控】

image
image1408×223 39.2 KB

image
image

2

SELECT * FROM INFORMATION_SCHEMA.statements_summary;
这个表现在多少条数据？

3

image

4

干嘛要所有都记下来啊，这个东西占内存的，记差不多就行了

5

这个修改主要占点内存，6000还小的话，可以改成10000，不过存这么多sql也没啥大用吧。。。

6

主要为了tidb-dashboard中的语句分析，不然会出现other分类。
官方文档也说，如遇到改情况，对性能也有一些影响，建议调大：

image
image2412×369 185 KB

它会仅保留tidb_stmt_summary_max_stmt_count数量下的最近24条，内存足够是不是就可以无限增加了

7

也可以改成十万。。。。

8

可以加到满意为止哈

9

你们tidb配置的都是多少呢？你们会用到tidb-dashboard的语句分析吗？

10

@tidb团队， 内存足够的情况下，有没有建议呢？

11

不怕使用SQL分析的时候oom，就可以调大 :bomb:

12

可以调大

13

有没有其他影响，例如上面说的sql分析oom。tidb更推荐如何配置？ 目前tidb服务器内存是足够的。

14

目前的限制

由于 statement summary tables 默认都存储在内存中，TiDB server 重启后，statement summary 会全部丢失。

为解决该问题，TiDB v6.6.0 实验性地引入了 statement summary 持久化功能，该功能默认为关闭。开启该功能后，历史数据不再存储在内存内，而是直接写入磁盘。TiDB server 重启后，历史数据也依然可用。

持久化 statements summary

警告

statements summary 持久化目前为实验特性，不建议在生产环境中使用。该功能可能会在未事先通知的情况下发生变化或删除。如果发现 bug，请在 GitHub 上提 issue 反馈。

如目前的限制一节所描述，默认情况下 statements summary 只在内存中维护，一旦 TiDB server 发生重启，所有 statements summary 数据都会丢失。自 v6.6.0 起，TiDB 实验性地提供了配置项 tidb_stmt_summary_enable_persistent 来允许用户控制是否开启 statements summary 持久化。

如果要开启 statements summary 持久化，可以在 TiDB 配置文件中添加如下配置：

[instance]
tidb_stmt_summary_enable_persistent = true
# 以下配置为默认值，可根据需求调整。
# 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

开启 statements summary 持久化后，内存中只维护当前的实时数据，不再维护历史数据。历史数据生成后直接被写入磁盘文件，写入周期参考参数配置一节所描述的 tidb_stmt_summary_refresh_interval。后续针对 statements_summary_history 或 cluster_statements_summary_history 表的查询将结合内存和磁盘两处数据返回结果。
https://docs.pingcap.com/zh/tidb/stable/statement-summary-tables#为-statement-summary-设定合适的大小

15

实验特性的statement summary tables可以写入硬盘，这样也不用担心OOM了，不过是实验特性，稳定性和BUG的风险还是有的，慎用！

16

根据实际生产，合适就好吧

17

调的太大很影响性能的

18

如果不完整统计（超出数量会分配到others），sql语句分析的作用是什么？

19

其实大部分问题符合20/80原则的。
关键的问题不是统计多少，而是这些统计能不能找到给你造成80%影响的那20%。
如果不能，再调大就好了。

1 个赞
20

这个东西不建议改，改大了会有风险。理由是，sql语句存的过多，有时候你去查，要decode 这个plan，有可能会导致数据库OOM。这个有对应的issue。就设置3000就行了，多余的本身就是不怎么活跃的，要不要无所谓。

1 个赞