建议设置成off，能保持执行计划的稳定，如果设置成 on，统计信息过期后使用 10000 行来评估，容易出现执行计划走错。

tidb-server 内存长时间保持在阈 tidb_server_memory_limit * tidb_server_memory_limit_gc_trigger 值以上时，会触发 issue unexpected cpu usage caused by tidb_server_memory_gc_trigger · Issue #48741 · pingcap/tidb · GitHub 导致 CPU 长时间处于较高使用状态。 在7.5.1 版本才解决。你可以升级试试。 [image]

可以先升级 v7.5.1 试试

看上去像是这个问题 https://github.com/pingcap/tidb/issues/48741

当前什么版本 ？

TiProxy 和 TiCDC 支持的新特性 Debezium

统计信息没有过期是什么问题呢 ？ SQL发出来看看呢。

还有一个路径也可以，就是查看 performance-overview 这个面板的这个会显示Active connections [image] [image]

最直接的就是在 prometheus 中查询 tidb_server_tokens 这个表达式，只有这个表达式才代表了并发连接。 tidb_server_tokens The number of concurrent executing session TYPE tidb_server_tokens gauge tidb_server_tokens 0

这个日志出现没关系，后面显示为 dump data successfully, dumpling will exit now。这个地方是 [info]

用/*+inl_join(tt1) */ 试一下。

最最上乘的办法就是通过统计信息来解决，但是这也是最难的。 统计信息解决不了的，才分两种情况。如果是出故障的就去绑定，没有出故障的就应用自己去解决。

其实存多了不能看，还不如不存多。只存主要的。 https://github.com/pingcap/tidb-dashboard/issues/1386 [image]

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

你可以研究一下这个工具 PCC pingcap A tool used to capture plan changes among different versions of TiDB [image]

我希望是能出现一个整合和总结的，比如你发一个问题，他先回复你如何解决，然后下面列出引用出处（比如论坛中的经验）。

看下 grafana 监控吧。像是压力太大了导致的，把 topsql 分析分析。

这个报错遇到过，一般是应用程序和数据库之间中断了。

你的 tidb_analyze_version 设置的多少？ 这个报错很明显了。only support analyze version 1 currently