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

今天遇到一个客户问我说,我从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时对数据业务还是有影响的,所以建议再备库执行或者在业务低峰期执行。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值