云数据库RDS-mysql多给我计算数据占用空间了吧?-阿里云开发者社区

开发者社区> 数据库> 正文

云数据库RDS-mysql多给我计算数据占用空间了吧?

简介: 今天遇到一个客户问我说,我从MySQL里统计我的数据占用空间只有500G左右,而云控制台和售后给我的数据都是数我的数据占用了1.5T左右的空间,那为啥有1T空间去哪里了?日志等其他文件所占空间也没有统计到数据文件中,那数据文件多占了1T的空间到底是怎么回事,是不是阿里多给我计算了占用的空间?         其实很简单,两种查询得方法肯定有不准确的地方,客户是在mysql的元数据表里information_schema.tables中查询的,而控制台显示的空间占用情况是RDS从OS层面获取的表文件占用空间情况。

今天遇到一个客户问我说,我从MySQL里统计我的数据占用空间只有500G左右,而云控制台和售后给我的数据都是数我的数据占用了1.5T左右的空间,那为啥有1T空间去哪里了?日志等其他文件所占空间也没有统计到数据文件中,那数据文件多占了1T的空间到底是怎么回事,是不是阿里多给我计算了占用的空间?


        其实很简单,两种查询得方法肯定有不准确的地方,客户是在mysql的元数据表里information_schema.tables中查询的,而控制台显示的空间占用情况是RDS从OS层面获取的表文件占用空间情况。说道这里大家估计都明白了,从OS层面获取应该更准确。那为啥两者差距这么大,那我们一起来看看information_schema.tables中的信息是怎么来的。


       查看相关文档发现information_schema.tables中的空间信息是通过采样加计算获取的一个估值,如果采样采集的点与实际数据占用情况区别不大时,这个估值才准确,如果说表的记录长短不一,或者表经过长时间DDL操作,采集点发生了变化,那么information_schema.tables存放的这个估值是不准确的,有可能与实际差距会很大。


      既然原因我们找到了,那么如何解决呢?

     MySQL提供重新采集的命令,analyze table  tablename,我们手动重新采集一下,再去做统计,就与控制台显示的空间占用情况基本一致了。


     为啥说“基本”一致而不是“完全”一致呢?因为实际情况每条记录不可能完全一样,而且总归是抽样计算,所以必然会有误差。但是差距不会很大,因为关系型数据库中单表存放的应该同样类型的数据。所以即使不同也是差距不大。


      那么这次重新采用了,随着数据库的数据变化,这个估值又会与实际存放值有较大差距,所以还是建议客户以控制台显示的空间占用情况为准,这才是最准确的。


下面拿一张表举个例子演示一下:


表t_growth_child_ID占用空间205G(OS层面获取)如下图


ed142a092bb03f75d2add17b078cc5f2cc21c746

 

从information_schema.tables的查询空间语句:



查询结果截图:

864ce0146d0261d9174335864ec7b354ef6ff2f3



重新采集截图:

45273c2a1b20a4b1b998ae2814a442e495b617a2


重新查询截图:

52bcdd772716d174168b014373a6d7df04c27e9e


如图数据空间和索引空间发生差异较大的变化,与直接从OS层面获取的数据文件大小基本一致。


另外注意,在进行analyze table时对数据业务还是有影响的,所以建议再备库执行或者在业务低峰期执行。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章