1小时，我看了db目录里面的sst文件 全是几十M到200M ，总共20多万个才达到2.7T ，2.7*17个TiKV=46T左右
其它的文件没占用啥空间
那就没太大差异，SST就是数据文件了 ，业务有多少条数据，数据类型都什么样
磁盘和监控是对的上，这个没问题，我的问题是数据库里字典查出来的数据量和监控对不上，这样就不知道哪些库表占用的最大
磁盘使用和监控是对的上，这个没问题，我的问题是数据库里字典查出来的数据量和监控对不上，这样就不知道实际哪些库表占用的最大
前面不都说了 架构决定的这里面不是准确的
监控上哪个监控项是代表数据量的?
regions X 94M X 3,这个算大小
我觉得可以这样算下 ，从tikv_region_status里计算每个table的总size 然后和整表的总size计算比例，然后用这个比例去乘以监控总大小，再除以3应该就是一个副本的大小 ，可能也不一定准确
这是因为两者计算的角度不一样。 information_schema.tables.data_length 是通过统计信息（平均每行的大小）得到的估算值。TiKV 监控面板上的 store size 是单个 TiKV 实例的数据文件（RocksDB 的 SST 文件）的大小总和。由于多版本和 TiKV 会压缩数据，所以两者显示的大小不一样。
现在是压缩后52T 字典只查到20T
现在是磁盘已经52T了 字典远远不到这个值，就不太好定位哪些库表是真实大了
information_schema.tables 里的数据量大小除以information_schema.tables里的行数这个估算出来的每行大小应该是准的，但是这个统计信息的总行数有可能是不准的，所以乘以真实行数如（select count(*) from t）出来的数据
这个查的所有表的数据和磁盘体现的容量差太多了，不知道差在哪？
是否可以找某张表，比如最大的表对比下在两种口径下的具体差异？
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。