前言
TiDB 如何统计数据库占用空间大小
四种方法
方法一
TiDB 统计数据库占用大小的第一种方法是监控。通过查看 {cluster-name} - Overview
，可以查看Current storage size
面板，获取当前集群已用数据库空间大小。这里显示占用15GB。
使用监控查看数据库大小有一个好处，它可以观测到历史的数据增长趋势。
方法二
第二种方法是根据统计信息来计算大小。使用tables
表中的AVG_ROW_LENGTH
和TABLE_ROWS
来进行计算，这个方法的缺点是很依赖于数据库统计信息的准确性。
mysql> select TABLE_SCHEMA,sum(AVG_ROW_LENGTH * TABLE_ROWS)/1024/1024/1024 from information_schema.tables group by TABLE_SCHEMA;
+--------------------+-------------------------------------------------+
| TABLE_SCHEMA | sum(AVG_ROW_LENGTH * TABLE_ROWS)/1024/1024/1024 |
+--------------------+-------------------------------------------------+
| METRICS_SCHEMA | 0.000000000000 |
| sbtest | 8.280010784045 |
| PERFORMANCE_SCHEMA | 0.000000000000 |
| mysql | 0.000000000000 |
| test | 8.530541450717 |
| INFORMATION_SCHEMA | 0.000000000000 |
+--------------------+-------------------------------------------------+
6 rows in set (0.01 sec)
如果数据库的统计信息不准，则计算出来的大小就不准，很显然我这里计算是不准的。
方法三
第三种方法使用了tidb-ctl
工具，我们知道Tikv
会把region
信息上报给PD，因此可以使用该工具在 tidb 里面用 table 跟 region 的映射关系估算出 table 的大小。
我们来试一下，随便查询一张表。
tiup ctl:v5.1.3 tidb table disk-usage -d sbtest -t sbtest1
Starting component `ctl`: /root/.tiup/components/ctl/v5.1.3/ctl tidb table disk-usage -d sbtest -t sbtest1
2624
我写了一个shell脚本，遍历了 sbtest 这个schema。
tmp=`mysql -uroot -hxxx -P4000 -Ne "SELECT table_name FROM information_schema.tables where TABLE_SCHEMA='$1'"|while read a ;do echo "$a";done`
sum=0
for i in $tmp
do
tablename=`echo $i |cut -d: -f 1`
tablesize=`tiup ctl:v5.1.3 tidb table disk-usage -d $1 -t $tablename`
sum=$[sum+tablesize]
done
echo $sum
执行结果，显示的是12980，换算出来大概是12.7G。果然和我们从统计信息查出来的差异大。而统计test库显示出大概是1.4G。这样两个库统计出来的数据就是14.1G，接近图1的监控值。
方法四
第四种方法是查看TABLE_STORAGE_STATS
视图。
mysql> select TABLE_SIZE from TABLE_STORAGE_STATS where TABLE_NAME='sbtest1' and table_schema='sbtest';
+------------+
| TABLE_SIZE |
+------------+
| 2624 |
+------------+
1 row in set (0.00 sec)
mysql> select sum(TABLE_SIZE) from TABLE_STORAGE_STATS where table_schema='sbtest';
+-----------------+
| sum(TABLE_SIZE) |
+-----------------+
| 12980 |
+-----------------+
1 row in set (0.02 sec)
这个视图查出来的数据和tidb-ctl
查出来的结果一致。
一个小疑问
这里有个很有意思的地方，之前为了分析客户的高耗SQL问题，在test下面导入了客户的一张表和统计信息（没导入数据）。正好可以用来验证方法二和方法三和四的正确性。
这张pro_ssk
当时只导了表结构和统计信息，没导入任何数据。
mysql> select count(1) from pro_ssk;
+----------+
| count(1) |
+----------+
| 0 |
+----------+
1 row in set (0.01 sec)
mysql> select TABLE_SCHEMA,sum(AVG_ROW_LENGTH * TABLE_ROWS)/1024/1024/1024 from information_schema.tables where table_name='PRO_SSK' group by TABLE_SCHEMA;
+--------------+-------------------------------------------------+
| TABLE_SCHEMA | sum(AVG_ROW_LENGTH * TABLE_ROWS)/1024/1024/1024 |
+--------------+-------------------------------------------------+
| test | 5.842046596110 |
+--------------+-------------------------------------------------+
1 row in set (0.01 sec)
[root@copy-of-vm-ee-centos76-v1 ~]# tiup ctl:v5.1.3 tidb table disk-usage -d test -t PRO_SSK
Starting component `ctl`: /root/.tiup/components/ctl/v5.1.3/ctl tidb table disk-usage -d test -t PRO_SSK
134
mysql> select TABLE_SIZE from TABLE_STORAGE_STATS where TABLE_NAME='PRO_SSK' and table_schema='test';
+------------+
| TABLE_SIZE |
+------------+
| 134 |
+------------+
1 row in set (0.01 sec)
通过统计信息查询该表占用空间5.84GB。我们用tidb-ctl
和TABLE_STORAGE_STATS
视图查看都只有134MB。
疑问来了，为什么空表还占用了134MB ？
我们可以先查出表的region id
。
mysql> select distinct REGION_ID from TIKV_REGION_STATUS where DB_NAME='test' and TABLE_NAME='PRO_SSK';
+-----------+
| REGION_ID |
+-----------+
| 22001 |
+-----------+
1 row in set (0.01 sec)
然后使用 tikv-ctl
查看这个region的大小。
tiup ctl:v5.1.3 tikv --host 172.16.4.212:20160 size -r 22001
Starting component `ctl`: /root/.tiup/components/ctl/v5.1.3/ctl tikv --host 172.16.4.212:20160 size -r 22001
[2022/03/05 19:46:50.873 +08:00] [INFO] [<unknown>] ["Disabling AF_INET6 sockets because ::1 is not available."]
[2022/03/05 19:46:50.873 +08:00] [INFO] [<unknown>] ["TCP_USER_TIMEOUT is available. TCP_USER_TIMEOUT will be used thereafter"]
[2022/03/05 19:46:50.874 +08:00] [INFO] [<unknown>] ["New connected subchannel at 0x7ffae622e210 for subchannel 0x7ffae9210d80"]
region id: 22001
cf default region size: 0B
cf write region size: 134.060MiB
cf lock region size: 0B
KV 数据最终存储在默认 RocksDB 内部的 default、write、lock 3 个 CF 内。这里可以看到cf write
是134MB的。
根据官网介绍
write
CF 存储的是数据的版本信息 (MVCC) 以及索引相关的数据
但是我这个表真的是空表，也没有做过更新和删除的操作，所以不应该有MVCC和索引的数据。
mysql> select distinct TABLE_NAME from TIKV_REGION_STATUS where REGION_ID =22001;
+-----------------------+
| TABLE_NAME |
+-----------------------+
| sbtest1 |
| aaa |
| a1 |
| seq2 |
| sbtest99 |
| PRO_SSK |
| sbtest5 |
+-----------------------+
7 rows in set (0.01 sec)
再次查询region
的信息，发现这个region
并不是一张表在使用，它还有其他表也在用，所以这130MB有可能是其他数据表的MVCC或者索引信息。所以方法三和方法四这么来看也是不准的。但是相对统计信息来说，还是要准不少的。
后记
以上是TiDB
统计数据库大小的四种方法，看整体大小占用直接看监控就行。如果要看单张表，建议使用tidb-ctl
工具或者是查看TABLE_STORAGE_STATS
视图。
refenerce
https://asktug.com/t/topic/1318
