为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】v5.0.3
【背景】 每天定时出现集群压力过大
【现象】
【问题】 集群压力过大，导致应用连接超时
【业务影响】 业务无法正常使用
【TiDB 版本】 v5.0.3
【应用软件及版本】
【附件】 相关日志及配置信息
监控
TiDB-Overview Grafana监控
TiDB Grafana 监控
TiKV Grafana 监控
对应模块日志（包含问题前后 1 小时日志）
logs-tidb_123_59_17_193_4000.zip (3.0 MB)
不过按照 你 tikv 的CPU 监控，怀疑你慢日志/热点导致的此问题，建议你按照 慢日志的方向来看一下
慢查询里面大量的这种 sql 各个字段采样统计应该是
– Metabase SELECT tbl_new_ssp_ad_log_20210529.planId AS planId FROM tbl_new_ssp_ad_log_20210529 GROUP BY tbl_new_ssp_ad_log_20210529.planId ORDER BY tbl_new_ssp_ad_log_20210529.planId ASC LIMIT 5000;
我们的需求是能不能有一个收集统计信息表的例外表，我们可以指定例外掉哪些历史表 不再自动收集统计信息
另外能不能设置收集时间凌晨1点开始 ，收集的并发度调低 ，中间加一下间隔时间什么的。
我记得5.0.1 的时候不是有 某个表更新多少比例的数据 才会触发analzye吗？ ，现在是大量的样本统计 把系统搞崩溃了 。 导致当时简单的insert 语句都需要30多s 才能执行完
可以加我微信 直接沟通吗？ heming_0120 希望能快速修避免影响明天清晨2个多小时 慢查询 。
或者你们可以指定某个库的统计信息不收集也行 ，我把历史表都集中扔到一个库里 避免统计信息收集
页面把图片压缩了，可以下载图片，这样就清晰了。 还需要哪个监控图？
可以看一下：tidb_enable_fast_analyze、 tidb_auto_analyze_end_time、 tidb_auto_analyze_ratio、 tidb_auto_analyze_start_time、 tidb_build_stats_concurrency。这几个参数 @heming
select @@tidb_enable_fast_analyze @@tidb_auto_analyze_ratio @@tidb_auto_analyze_start_time @@tidb_auto_analyze_end_time @@tidb_build_stats_concurrency
0 0.5 00:00 +0000 23:59 +0000 4
tidb_enable_fast_analyze 这个要设置为 1 吗？ tidb_build_stats_concurrency 这个设置为 2 或者 1 ？
1、收集统计信息，可以关闭，然后手工进行收集（可以写个定时任务）关闭收集统计信息的参数： run-auto-analyze https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#run-auto-analyze
2、上面提到的几个参数：分别可以控制 analyze 任务的运行时间，及触发条件，而tidb_enable_fast_analyze 则是收集统计信息的方式（这里牵扯 tidb 收集统计信息 和mysql 的兼容性），而tidb_build_stats_concurrency 等几个参数，则是控制收集任务的并发度之类（具体没有参考值，每个集群的数据量，业务形态不一样，没发给你明确的数值建议）https://docs.pingcap.com/zh/tidb/stable/statistics#查看-analyze-状态
这种SQL 是在做什么
这是业务 SQL 吧
建议你看看 tidb_slow.log看看关于这个语句的信息（或者发我一下）
建议你根据 connect id。username 来判断业务线是谁，确认一下这个 SQL是不是业务 SQL（这个不是 数据库内部执行 的 SQL）
好的，谢谢。 之前看有metabase，以为是统计信息的SQL
好的
，建议咱们1、看看慢日志 2、根据 dashboard 的 kv 功能，找到对应 读写较为高的表，查看表结构，是否能打散（热点的处理方式）（因为看咱们的 kv 截图，是有规律行的 几张特点的几个表，读写流量较高）
现在是range 按月 分区表的形式，还能有别的方式打散吗
