今天遇到一个客户问我说，我从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层面获取）如下图
从information_schema.tables的查询空间语句：
查询结果截图：
重新采集截图：
重新查询截图：
如图数据空间和索引空间发生差异较大的变化，与直接从OS层面获取的数据文件大小基本一致。
另外注意，在进行analyze table时对数据业务还是有影响的，所以建议再备库执行或者在业务低峰期执行。
