tidb7.5.1:部分宽表分区健康度一直是0,drop stats 和手动analyze也不行

你在你的环境别的表能复现吗? 或者用这个表结构建个类似的表试试能不能复现?

试过 直接 analyze 整张表吗?

有很多的分区表都有这个问题


另一个


整张表analyze没有试过,因为怕影响集群性能,一直是跑单个分区
这些分区表共同特点是历史分区做了合并,你看看和这个有关系吗

合并了同样没复现。。 方便的话可以再提供下对应时间点的 tidb-server 日志

或者是显示的bug?
synrpt_gdt_advertiser_request_part.log.gz (57.3 KB)

synrpt_gdt_advertiser_reporting_part.log.gz (839.7 KB)

可以删除重建试试

对应分区是不是没有数据,count 下,没有数据我记得是不构建统计信息的。


有数据的


手动 Analyze 一下,然后看下这个 warning:show warnings;

Hello,

发生问题的表,表结构都类似吗?比如都是大宽表,分区都是 PARTITION BY RANGE COLUMNS(date)。
非宽表是否有此情况发生?

麻烦查下 SHOW STATS_META where table_name = ‘synrpt_gdt_adgroup_request_part_v3’;

麻烦尝试设置 set @@session.tidb_partition_prune_mode = ‘static’ 后,进行单独分区的 analyze,看是否成功。

1、出问题的都是宽表,分区键都是date
2、改成静态,貌似没效果

有点奇怪,为啥你图里analyze table的分区是p20240501,查出来的又没有这个分区,看着healthy为0的分区是从p20240507到p20240521,这些分区再单独analyze table收集下统计信息看看。

因为健康度是0 ,所以做了analyze。analyze之后还是0,就drop stats 之后再analyze。结果就是健康度和统计信息都看不到这个分区了

  1. 更新统计信息:您可以尝试运行ANALYZE TABLE命令来更新表的统计信息,以便TiDB能够更准确地评估分区健康度。
  2. 优化表设计:检查表设计,确保有适当的索引来支持查询。如果必要,考虑重构表或添加索引。
  3. 平衡数据分布:检查数据分布,如果发现某些分区负载过重,可以考虑重新分区或调整数据插入策略。
  4. 提升系统资源:确保系统有足够的资源来支持TiDB的运行。如果资源不足,可能需要增加硬件资源或优化现有资源的使用。

又找了个分区表,做了全局analyze,global健康度74,但是大部分区分健康度是0
猜测是analyze是成功的,只不过健康度显示出bug了

我看了下你的第一个日志,这里面分析的就是缺分区 P20240501 的表吧?日志里面没看到你分析这个分区的记录。有一些其他的分区。
另外你可以用 P20240501 的物理 id 在 mysql.stats_meta 里面找找看有没有这个分区的记录。
也可以在 mysql.analyze_jobs 里面找一找这个分区相关的记录。看看上次成功是什么时候。

drop stats之后 ,多次手动analyze就看不到了

但是可以看到上次成功是手动analyze

你第一个是看的哪个表?是 mysql.stats_meta 吗

更新图片了