如何准备评估某张表的大小

如题, 尝试了以下三种查询,结果相差甚远。如何正确评估表大小呢??

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 = 'test'
            AND table_name IN ('example_table2')
    GROUP BY db_name , table_name , region_id) tabinfo
GROUP BY db_name , table_name;

±--------±---------------±-----------------±----------+
| db_name | table_name | Approximate_Size | Disk_Size |
±--------±---------------±-----------------±----------+
| test | example_table2 | 647.00 | 599.07 |
±--------±---------------±-----------------±----------+

select
table_schema ,
table_name,
table_rows ,
truncate(data_length/1024/1024, 2) as 'data(MB)',
truncate(index_length/1024/1024, 2) as 'index(MB)'
from information_schema.tables
where table_schema='test'
and table_name='example_table2'
order by data_length desc, index_length desc;

±-------------±---------------±-----------±---------±----------+
| table_schema | table_name | table_rows | data(MB) | index(MB) |
±-------------±---------------±-----------±---------±----------+
| test | example_table2 | 8000000 | 256.34 | 122.07 |
±-------------±---------------±-----------±---------±----------+

select A.* 
from INFORMATION_SCHEMA.TABLE_STORAGE_STATS A , information_schema.tables B 
where A.table_id=b.TIDB_TABLE_ID and A.table_schema='test' and A.table_name='example_table2';

±-------------±---------------±---------±-----------±-------------±-------------------±-----------±-----------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | PEER_COUNT | REGION_COUNT | EMPTY_REGION_COUNT | TABLE_SIZE | TABLE_KEYS |
±-------------±---------------±---------±-----------±-------------±-------------------±-----------±-----------+
| test | example_table2 | 178 | 3 | 1 | 0 | 36 | 532480 |
±-------------±---------------±---------±-----------±-------------±-------------------±-----------±-----------+
1 row in set (0.03 sec)

先看看评估的目的是什么,搜索sql扫描的key还是参考information_schema.TIKV_REGION_STATUS
计算导出的数据量参考information_schema.tables
计算磁盘占用还得看压缩比

1 个赞

官方文档是第一种
https://docs.pingcap.com/zh/tidb/stable/manage-cluster-faq#如何预估-tidb-中一张表的大小

可以参考一下之前大拿整理的

2 个赞

除了系统表外,还要经验预估大小

得根据实际情况看,有的看tables, 有的看table_storage_stats,等等

用第一种

计算单副本大小和磁盘占用空间通常用 information_schema.TIKV_REGION_STATUS 表,从region维度聚合计算得到,即方式一。

从集群统计信息采样获取到表大小,通常用 information_schema.tables 。

官方描述如何预估 TiDB 中一张表的大小,用的就是第一种方式,这个相对比较准确了,但是SQL可能有点复杂。如果是粗略快速查看, information_schema.tables 可能相对简单一点。

1 个赞

一般都是用官方提供的版本

第一个方案的查询利用了 TiDB(或兼容TiDB的分布式数据库)的information_schema.TIKV_REGION_STATUS 视图,它提供了每个region的详细存储信息。这个查询考虑了数据在不同region上的分布,以及可能的放大因子(通过store_size_amplification ),因此结果可能包含了由于复制、索引或其他内部机制导致的数据放大效应,比较接近实际占用的存储空间。

我之前也试过跟br导出对比,目前没找到很准确估算一张表大小的方法,官方的SQL查询应该跟表的高水位有关系

1 个赞

看来官方推荐的第一种较为准确,从region上进行聚合,并考虑到了压缩比,第二种的评估相对粗一些

1 个赞

官方推荐的第一种

目前没有精确计算的方法,估算Dumpling 出的数据大小,用方法二

是个很好的话题。
另外同问TIDB需要经常做碎片整理吗?

好问题学习了,同问需不需要经常optimize

建议用官方提供的版本

第一种是官方提供的,是准确的

官方推荐是使用第一种: TiDB 集群管理常见问题 | TiDB 文档中心 (pingcap.com)

官方是第一种,这种是有显示压缩后的大小,tidb的数据是默认经过压缩的。Approximate_Size是压缩前大小,disk_size是压缩后实际磁盘占用大小。
第二个是mysql的查询表大小方式。计算方式和tidb可能会有些差别。

information_schema.tables里面有data,index的字段查询