TIDB 表统计空间占用量与实际数据量相差很多

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】v5.1.4
【复现路径】
【遇到的问题：问题现象及影响】
生产环境有个表，总共5000多行数据，但是 INFORMATION_SCHEMA.TIKV_REGION_STATUS 统计的结果，空间占用了1300多GB，业务的场景是，此表会频繁的更新某个字段值，会用到事务

mysql> select DB_NAME,TABLE_NAME,sum(APPROXIMATE_SIZE)/1024 as table_size_G from INFORMATION_SCHEMA.TIKV_REGION_STATUS where DB_NAME not in ('INFORMATION_SCHEMA','METRICS_SCHEMA','PERFORMANCE_SCHEMA') and TABLE_NAME="bucket" group by DB_NAME,TABLE_NAME order by table_size_G desc limit 100;
+----------+------------+--------------+
| DB_NAME  | TABLE_NAME | table_size_G |
+----------+------------+--------------+
| xxxxxx | bucket     |    1293.7627 |
+----------+------------+--------------+

数据量

mysql> select count(1) from bucket;
+----------+
| count(1) |
+----------+
|     5029 |
+----------+

使用了analyze table 命令，但是看起来，统计的结果依旧有问题

2

APPROXIMATE_SIZE 单位是字节 兄台是否少除了一个1024 而且这个值是一个估计值 并不能完全准确的反映表大小

3

看一下 IS_INDEX 列 0 代表不是索引，1 代表是索引

4

APPROXIMATE_SIZE：Region 的近似数据量 (MB)

单位是 MB的 不是字节，兄台，你记岔劈了

5

IS_INDEX 搞个 group by 就可以看出是 索引占的大，还是数据了

6

sum(APPROXIMATE_SIZE)/1024 单位是G没错的

7

检查下gc推进情况，不会长时间没gc吧

1 个赞
8

我查表数据占用大小是从INFORMATION_SCHEMA.tables 里面查询的
select TABLE_SCHEMA,TABLE_NAME, round(data_length/1024/1024,2),TABLE_ROWS from tables order by DATA_LENGTH desc
你看看2个表统计一致吗

9

查了下官方给的查询一张表的数据占用大小

如何预估 TiDB 中一张表的大小？

要预估 TiDB 中一张表的大小，你可以参考使用以下查询语句：

SELECT
    db_name,
    table_name,
    ROUND(SUM(total_size / cnt), 2) Approximate_Size,
    ROUND(SUM(total_size / cnt / (SELECT
                    ROUND(AVG(value), 2)
                FROM
                    METRICS_SCHEMA.store_size_amplification
                WHERE
                    value > 0)),
            2) Disk_Size
FROM
    (SELECT
        db_name,
            table_name,
            region_id,
            SUM(Approximate_Size) total_size,
            COUNT(*) cnt
    FROM
        information_schema.TIKV_REGION_STATUS
    WHERE
        db_name = @dbname
            AND table_name IN (@table_name)
    GROUP BY db_name , table_name , region_id) tabinfo
GROUP BY db_name , table_name;

在使用以上语句时，你需要根据实际情况填写并替换掉语句里的以下字段：

  • @dbname：数据库名称。
  • @table_name：目标表的名称。

此外，以上语句中：

  • store_size_amplification 表示集群压缩比的平均值。除了使用 SELECT * FROM METRICS_SCHEMA.store_size_amplification; 语句进行查询以外，你还可以查看 Grafana 监控 PD - statistics balance 面板下各节点的 Size amplification 指标来获取该信息，集群压缩比的平均值即为所有节点的 Size amplification 平均值。
  • Approximate_Size 表示压缩前表的单副本大小，该值为估算值，并非准确值。
  • Disk_Size 表示压缩后表的大小，可根据 Approximate_Size 和 store_size_amplification 得出估算值。
2 个赞
10

像风一样的男子很专业 :smiley:

11

官方文档里面的，实际上这么查也没多大用

12

:+1: :+1: :+1:这个是最接近实际值的，官方认证的

1 个赞
13

解决不了实际问题，比如为什么5000条数据占用1300G空间

14

索引数据也在这个表

15

所以要看下 IS_INDEX 列 到底是 数据 占得，还是索引占得

16

可能是频繁新增、修改、删除数据，存在未合并的region或者未gc的历史版本吧。

1 个赞
17

APPROXIMATE_SIZE：Region 的近似数据量 (MB)看看

18

只对这个表做下compact ,加-c write -d kv
mysql -uroot -pXXX -hxxx -PXXX information_schema -e “select region_id from tikv_region_status WHERE DB_NAME NOT IN ( ‘INFORMATION_SCHEMA’, ‘METRICS_SCHEMA’, ‘PERFORMANCE_SCHEMA’ ) AND TABLE_NAME = ‘bucket’ ”>region_list
cat region_list|while read line
do
tiup ctl:v5.1.4 tikv --host xxxx:20160 compact -r $line -d kv -c write --threads 1 --bottommost force
tiup ctl:v5.1.4 tikv --host xxx:20160 compact -r $line -d kv -c default --threads 1 --bottommost force
done

1 个赞
19

看了下是真实的数据

20

DBA 查到GC 长期未执行，找DBA跟进下看看先

2 个赞