【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】7.1
【遇到的问题：问题现象及影响】
最近在测试热点表缓存，有个疑问，官方说表数据总大小限制不超过 64MB，我想缓存的表大小具体是多少，就是 64MB大小判断用的具体sql是什么？
如何预估 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得出估算值。
官方说是预估值，不见得是实际值，实际值估计还需要一些方法探讨
1 个赞
那我问题里面的64m看这个查询结果哪个值
执行下ALTER TABLE t CACHE看看会不会失败就知道了
是的，既然有64m限制，操作前应该知道这个表和64m差距
64M=1024x64kb=1024x1024x64字节=67,108,864字节，排除索引什么的，varchar(10000)可以存6710条记录，纯手算，不知道对不对。
验证了一下，是按这个值判断的 
大概能存2200多条varchar(10000)的记录
SELECT ROUND(DATA_LENGTH/1024/1024,2) FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema = 'test'
AND table_name = 'users2'
1 个赞
这个语句有一个问题，就是数据量减少的时候，这个值不变，我试了好几次。 数据量增加的时候，这个值倒是变的。
减少后是不是没有gc 容包括mvcc历史数据
很有可能
老师，如果是按照这个值估算表的大小和64M 做比较，那么这个语句查询表的大小是否可以理解成是准确的，因为之前有看到过说是这个查询表的大小结果是不准确的
之前，tidb 的库mysql 做的备份，tidb中查询大小差不多700G 左右，mysql里面查询大约1.3T ，都是用的musql查询数据库的大小的语句查询的SELECT ROUND(DATA_LENGTH/1024/1024,2) FROM INFORMATION_SCHEMA.TABLES —这种sql
tidb数据存在regions里面，默认有3个副本，包括mvcc内容也在region里面，存储时候是压缩的，压缩比也不小，所以大小估计有点难
是的 ，所以不知道到底这个数据量是哪个为准，本身就是3副本，数据有冗余
这个语句是和那个参数对应的，不是和实际物理文件大小对应的，之前我们经常讨论的是物理文件大小。物理文件大小应该和一楼发的那个语句对应的。
好的，谢谢 ，理解了
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。