【 TiDB 使用环境】生产环境
【 TiDB 版本】V8.1.0
【复现路径】tidb v8.1.0，查询information_schema.tables的rows、data_length、data_length都为0，有重启pd节点、tidb集群都无效
【遇到的问题：问题现象及影响】
tidb V8.1.0，查询information_schema.tables的rows、data_length、data_length都为0，有重启pd节点、tidb集群都无效。对表进行analyze table重新收集统计信息后，还是存在大量为0的表，实际表都是有数据的。并且我在tidb01 server节点收集统计信息，其他节点也还是为0
【附件：截图/日志/监控】
上个集群配置看看
我记得好像是2000行以下不会自动analyze，不确定是否影响手动。你看看这些analyze之后还是显示为0的，是不是不足2000行。
表数据量都特别大
1 个赞
换个节点analyze试试
show stats_healthy看看表的健康度
搜集统计信息是指定这个表搜集的，还是由系统自动搜集的，如果是系统自动搜集，看看是否这个表的搜集已经完成，有可能还在搜集进行中，还没有到这个表。
information_schema.tables中的信息变化，是否由搜集统计信息来触发，这个我不确定，我个人觉得好像是由不同的机制来触发更新的。
需要在每个节点分别执行analyze才行，并且每次重启tidb server之后，所有的都为0了
show stats_healthy 健康度大多数都在95以上
analyze 表名也不行？
手动在每个节点analyze之后可以，重启后又为0
tidb_analyze_version变量值是多少？
https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_analyze_version-从-v510-版本开始引入
默认版本：2
不会是溢出了吧。
2可能会导致OOM，但是手工执行正常，应该不是这里的原因。
information_schema.tables 的 rows（show stats_meta）、data_length（show stats_histograms）、data_length 三个字段均是从 tidb-server 内存的统计信息计算得来。结果的准确性依赖于统计信息的准确性，新 analyze 的表的数据准确度会接近于真实数据 (but ，不等于物理大小，tikv 数据默认多副本且带有压缩)。
如果 information_schema.tables 的 rows、data_length、data_length 数据长度为为 0 且表是实际有数据的，那么大概率是统计信息没有及时加载到内存里来。
建议找一个长度为零的表看一下统计信息
SHOW STATS_HISTOGRAMS WHERE table_name = 't2';
SHOW STATS_META WHERE table_name = 't2';
# 查询的时候注意表名大小写问题
ps: tidb 重启后统计信息加载需要一定的时间,加载完成标志可以查看 tidb.log ‘init stats info time’
ps: 对于直方图、TopN、CMSketch 等占用空间较大的统计信息，为了确保 SQL 执行的性能，TiDB 会按需进行异步加载。例如，对于直方图，只有当某条 SQL 语句的优化阶段使用到了某列的直方图统计信息时，TiDB 才会将该列的直方图信息加载到内存。按需异步加载的优势是统计信息加载不会影响到 SQL 执行的性能，但在 SQL 优化时有可能使用不完整的统计信息。
应该不是OOM，我这好几个8.1.0版本的都有问题。7.5.0版本没问题
我在tidb6.5.7版本下测了一下，information_schema.tables中的data_length,table_rows更新不与analyze绑定。在插入数据后，立刻查询information_schema.tables，各项数据为0，但隔了不到1min后，data_length,table_rows就都有值了。而此时我是禁用了auto analyze的，并且也没有手动搜集统计信息。
测试：
CREATE TABLE tbl (
id int(11) DEFAULT NULL,
cdate datetime DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ;
mysql> select data_length,index_length,table_rows from information_schema.tables where table_name=‘tbl’;
±------------±-------------±-----------+
| data_length | index_length | table_rows |
±------------±-------------±-----------+
| 0 | 0 | 0 |
±------------±-------------±-----------+
mysql> show analyze status;
Empty set (0.01 sec)
mysql> show global variables like ‘%analyze%’;
±---------------------------------------±------------+
| Variable_name | Value |
±---------------------------------------±------------+
| tidb_analyze_partition_concurrency | 1 |
| tidb_analyze_version | 2 |
| tidb_auto_analyze_end_time | 23:59 +0000 |
| tidb_auto_analyze_partition_batch_size | 1 |
| tidb_auto_analyze_ratio | 0.5 |
| tidb_auto_analyze_start_time | 00:00 +0000 |
| tidb_enable_analyze_snapshot | OFF |
| tidb_enable_auto_analyze | OFF | --关闭了自动搜集
| tidb_enable_fast_analyze | OFF |
| tidb_max_auto_analyze_time | 43200 |
| tidb_mem_quota_analyze | -1 |
| tidb_persist_analyze_options | ON |
插入数据：
insert into test.tbl(id) values(1),(2),(3),(4),(5),(6),(7),(8),(9),(10),(11),(12),(13);
…
mysql> select count(1) from test.tbl;
±---------+
| count(1) |
±---------+
| 212992 |
±---------+
mysql> select data_length,index_length,table_rows from information_schema.tables where table_name=‘tbl’;
±------------±-------------±-----------+
| data_length | index_length | table_rows |
±------------±-------------±-----------+
| 0 | 0 | 0 |
±------------±-------------±-----------+
mysql> show stats_meta where table_name=‘tbl’;
±--------±------------±---------------±--------------------±-------------±----------+
| Db_name | Table_name | Partition_name | Update_time | Modify_count | Row_count |
±--------±------------±---------------±--------------------±-------------±----------+
| test | tbl | | 2024-11-19 18:01:20 | 212992 | 212992 |
±--------±------------±---------------±--------------------±-------------±----------+
mysql> select data_length,index_length,table_rows from information_schema.tables where table_name=‘tbl’;
±------------±-------------±-----------+
| data_length | index_length | table_rows |
±------------±-------------±-----------+
| 3407872 | 0 | 212992 |
±------------±-------------±-----------+
从如上测试可看出，information_schema.tables中的相关属性不更新，与analyze不绑定。因此需要看看是否踩中了bug。
感觉是8.1的bug，我8.1的几套环境都是同样问题
即使是 bug 也需要详细的信息去推断，建议找一个具体实例具体表看看