表健康度96%但是STATS_HISTOGRAMS所有的列都是allEvicted状态

🪐 TiDB 技术问题
,
1

一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题

【TiDB 使用环境】生产环境
【TiDB 版本】V8.5.3
【集群数据量】
【集群节点数】
【问题复现路径】发现部分sql执行计划没有走索引，执行SHOW STATS_HISTOGRAMS WHERE table_name = ‘xxx’;看到所有的列和索引都是 allEvicted状态，然后执行analyze table xxx finished状态后看到仍然是allEvicted状态。集群的磁盘，负载等目前是正常的，之前磁盘有超过83%，后来进行了扩容。
进一步查询到： SHOW STATS_HISTOGRAMS 所有的列状态都为allEvicted，SHOW STATS_BUCKETS全部为空

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】

2026-03-03 08:22:23 (UTC+08:00)

TiDB 10.131.178.142:4000

[rule_collect_plan_stats.go:279] [“SyncWaitStatsLoad failed”] [error=“sync load stats timeout”]

2026-03-03 08:22:23 (UTC+08:00)

TiDB 10.131.178.142:4000

[stats_syncload.go:141] [“SyncWaitStatsLoad meets error”] [errors=“["sync load took too long to return","sync load took too long to return","sync load took too long to return","sync load took too long to return","sync load took too long to return"]”]

2026-03-03 08:22:23 (UTC+08:00)

TiDB 10.131.178.142:4000

[stats_syncload.go:141] [“SyncWaitStatsLoad meets error”] [errors=“["sync load took too long to return"]”]
【其他附件：截图/日志/监控】

2

你扩容的这个tidb-server节点应该也同时出现了内存使用率上升、CPU升高的现象，根本原因是由于统计信息没有加载到内存中。

从 v7.1.0 开始，TiDB 引入了配置参数 lite-init-stats，用于控制是否开启轻量级的统计信息初始化。

  • 当 lite-init-stats 设置为 true 时，统计信息初始化时列和索引的直方图、TopN、Count-Min Sketch 均不会加载到内存中。
  • 当 lite-init-stats 设置为 false 时，统计信息初始化时索引和主键的直方图、TopN、Count-Min Sketch 会被加载到内存中，非主键列的直方图、TopN、Count-Min Sketch 不会加载到内存中。当优化器需要某一索引或者列的直方图、TopN、Count-Min Sketch 时，这些统计信息会被同步或异步加载到内存中。
    从 v7.1.0 开始，TiDB 引入了配置参数 force-init-stats。你可以使用该配置参数控制 TiDB 启动时是否在统计信息初始化完成后再对外提供服务。该配置参数从 v7.2.0 起默认开启。
    force-init-stats当前版本默认为true，表示提供服务之前，都会强制初始化统计信息，也就是上面日志中看到的耗时1秒的统计信息初始化过程，但该过程由于lite-init-stats为true，并不会加载到内存中。
    当 lite-init-stats 为 false 时，统计信息初始化时索引的直方图、TopN、Count-Min Sketch 会被加载到内存中，主键和列的直方图、TopN、Count-Min Sketch 不会加载到内存中。当优化器需要某一主键或列的直方图、TopN、Count-Min Sketch 时，这些统计信息会被同步或异步加载到内存中

所以将lite-init-stats改为false，重启tidb-server节点可以解决这个问题。最好编辑下集群配置文件tiup cluster edit-config xxx，把performance.lite-init-stats: false加到server config中，否则下次重启会失效。

3
  • 磁盘使用率过高时，TiDB 会触发统计信息的驱逐机制，且扩容后未触发统计信息的重新加载 / 生成；
  • 统计信息相关的系统参数配置不合理，导致 analyze 执行后统计信息无法留存。
4

MySQL [(none)]> show variables like ‘%ana%’;
±----------------------------------------±--------------------------------------------------+
| Variable_name | Value |
±----------------------------------------±--------------------------------------------------+
| tidb_analyze_column_options | ALL |
| tidb_analyze_distsql_scan_concurrency | 4 |
| tidb_analyze_partition_concurrency | 1 |
| tidb_analyze_skip_column_types | json,blob,mediumblob,longblob,mediumtext,longtext |
| tidb_analyze_version | 2 |
| tidb_auto_analyze_concurrency | 1 |
| tidb_auto_analyze_end_time | 22:00 +0000 |
| tidb_auto_analyze_partition_batch_size | 3 |
| tidb_auto_analyze_ratio | 0.2 |
| tidb_auto_analyze_start_time | 16:00 +0000 |
| tidb_enable_analyze_snapshot | OFF |
| tidb_enable_auto_analyze | ON |
| tidb_enable_auto_analyze_priority_queue | ON |
| tidb_enable_fast_analyze | OFF |
| tidb_max_auto_analyze_time | 43200 |
| tidb_mem_quota_analyze | -1 |
| tidb_persist_analyze_options | ON |
±----------------------------------------±--------------------------------------------------+
大佬我的参数是这样的，ananlyze以后还是没有留存统计信息

5

磁盘使用率超过 83%，可能导致 TiDB 在持久化统计信息到 mysql.stats_* 系统表时失败，统计信息未能正确写入磁盘。扩容后，虽然磁盘空间恢复，但损坏或缺失的统计信息文件并未自动修复。

6

大佬，扩容后，有重新触发annalyze table，tidb显示分析finished，但是仍然没有统计信息

7

修改完成，reload重启了tidb的节点，没有改善

8

手动执行以下分析操作,应该可以状态改善吧

9

效果不明显，无论怎么分析都改变不了执行SHOW STATS_HISTOGRAMS WHERE table_name = ‘xxx’;看到所有的列和索引都是 allEvicted状态

10

mark

11

最终查明原因是自己操作失误，将统计信息的缓存内存大小的参数调的过低导致，大家注意该参数的单位为0的时候默认是百分之比，但是配置了述职后单位默认是字节

12

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