【 TiDB 使用环境：生产环境】
【 TiDB 版本：6.5版本】
【遇到的问题： 无数据统计信息会无缘无故丢失，在手工运行ANALYZE TABLE xxx;之后才会重新出来。这样会导索引使用错误并造成集群资源消耗严重甚至不可用。PS：每运行一定时间后（如下午正常，凌晨就会出问题了）SHOW STATS_HEALTHY 为空，直至重新手动运行ANALYZE TABLE 语句】
【资源配置 TIDB server+PD server 16核32G ，TIKV * 3 32核64G】
以下是一些可能的原因和解决方法：
- TiDB自动统计信息功能未开启或配置不正确：TiDB默认开启了自动统计信息功能，但是如果您的TiDB版本较旧或者配置不正确，可能会导致自动统计信息功能未开启或者无法正常工作。您可以检查TiDB的配置文件中是否开启了自动统计信息功能，并且检查相关配置参数是否正确。
- 统计信息自动更新频率不够高：TiDB默认的统计信息自动更新频率较低，可能会导致统计信息丢失。您可以尝试调整TiDB的配置文件中的相关参数，增加统计信息自动更新的频率。
- 统计信息手动更新不及时：如果您的TiDB集群中存在大量的数据变更，可能会导致统计信息无法及时更新。您可以尝试手动更新统计信息，以确保统计信息的及时性。
也可以看下以下的这篇内容：
问题1：有开启自动ANALYZE ,当前的ANALYZE 版本=2.如果有一张表ANALYZE 过程中OOM会引起SHOW STATS_HEALTHY 为空吗？
问题2：其实核心想问的是为什么STATS_HEALTHY 为什么在运行一段时间后会为空，直到手动运行ANALYZE TABLE后才会出来。（出来后集群使用也就正常了），并且这与解答的自动ANALYZE 并无关系吧，因为即使我手动执行了ANALYZE 为什么一段时间后也同样消失呢？
如果TiDB自动ANALYZE功能已经开启，并且ANALYZE版本为2，那么在ANALYZE过程中OOM可能会导致SHOW STATS_HEALTHY为空。这是因为在ANALYZE过程中，TiDB会占用一定的内存资源，如果内存资源不足，可能会导致ANALYZE失败或者OOM，从而导致SHOW STATS_HEALTHY为空。
另外，如果一张表的统计信息丢失或者不准确，可能会导致SHOW STATS_HEALTHY为空。在这种情况下，您可以手动运行ANALYZE TABLE语句来更新统计信息，以确保SHOW STATS_HEALTHY的准确性。
总之，SHOW STATS_HEALTHY为空可能是由于多种原因导致的，包括统计信息丢失、ANALYZE失败或OOM等。
好的，多谢！我有一张表确实很大，我尝试去掉此表避免ANALYZE 时的OOM问题后再观察一下，多谢啦！
1 个赞
好叻，希望你能解决这个问题~
1 个赞
请问下能否有什么方法可以支持看到当前TIDB server 所在的机器CPU超过40%时所执行的SQL列表？好用于排查到底是哪些SQL会引起CPU飙升的问题呢？谢谢！
可以通过 TiDB Dashboard 的 Top SQL 页面来查看当前 TiDB 集群中执行时间最长的 SQL 语句，以及它们的执行计划和统计信息。同时，TiDB Dashboard 还提供了 CPU Profile 和 Flame Graph 等工具，可以帮助你更深入地分析 SQL 语句的执行情况，找出 CPU 飙升的原因。
具体操作步骤如下：
- 打开 TiDB Dashboard，进入 Top SQL 页面。
- 在页面上方选择要查看的时间范围和 SQL 类型。
- 查看执行时间最长的 SQL 语句，并点击“查看执行计划”按钮，查看 SQL 语句的执行计划和统计信息。
- 如果需要更深入地分析 SQL 语句的执行情况，可以使用 CPU Profile 和 Flame Graph 工具。在 Top SQL 页面中，点击 SQL 语句后面的“CPU Profile”或“Flame Graph”按钮，即可打开相应的工具界面。
在 CPU Profile 和 Flame Graph 工具界面中，可以看到 SQL 语句执行过程中各个函数的 CPU 消耗情况，以及函数之间的调用关系。通过分析这些信息，可以找出 CPU 飙升的原因，并进行相应的优化。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。