当发现数据库的容量很诡异的时候...-白红宇

今天接收到金山云的报警邮件，说有一个数据库出现了容量紧张的情况，我登上控制台一看，如图：

然后我登陆mysql client，在命令行里查询数据库的大小却是得到这样的值：

再用“select sum(data_length + index_length + data_free) / 1024 / 1024 from information_schema.tables;”这个语句来查看，结果如图：

由于数据文件在频繁的 DML 后会出现数据空洞的现象，所以下面这个语句其实更准一丢丢，两者差不多都是71G左右，与控制台网页说的占用了90G相差了近乎20个G，那么差距在哪里呢？

其实很简单，上面两个语句查的都是数据文件的大小，但是数据文件大小并不等于数据库里全部内容的大小，因为数据库的“存储空间”里还是有其他的文件的。

在命令行使用“show binary logs;”看看binlog的情况，插播一句，binlog 文件记录实例的事务信息，是 RDS MySQL 实例 HA 架构以及高可用性、可恢复性的基础，是不可以关闭的。我粗略的算了一下binlog文件大约有5G左右，与控制台显示的90G容量还是有15G左右的出入。这个时候，我记得曾经看过这样一句话：“如果存在对一个 InnoDB 表长时间不结束的查询，而且在查询过程中表有大量的数据变化，则会生成大量的 Undo 信息，导致 ibdata1文件尺寸增加。由于 MySQL 内部机制的限制，ibdata1 文件目前是不支持收缩的。”

于是就要查询一下ibdata文件的大小，但是由于我是mysql client，而查询ibdata是要使用innochecksum命令在mysql server段操作的，于是就拜托金山的售后帮忙查询一番，金山那边查了一下，告诉我ibdata文件的大小是144M，在那消失的15G面前完全就是忽略不计。

这里再额外说一句，ibdata文件不大就说明数据库的慢操作很少，运行状态还算正常。

这时，我就详细查了一下里面每一个tables的情况，使用语句：

                         
SELECT CONCAT(table_schema,
'.'
,table_name) AS 
'Table Name'
,   
    
table_rows AS 
'Number of Rows'
,   
    
CONCAT(ROUND(data_length/(1024*1024*1024),6),
' G'
) AS 
'Data Size'
,   
    
CONCAT(ROUND(index_length/(1024*1024*1024),6),
' G'
) AS 
'Index Size'
,   
    
CONCAT(ROUND((data_length+index_length)/(1024*1024*1024),6),
' G'
) AS
'Total'
FROM information_schema.TABLES   
WHERE table_schema LIKE 
'要查询的数据库名'
;
        
      

效果如下：

然后又麻烦金山方面du了一下数据大小的具体分布，做容量的对比，金山反馈的结果如图：

两边的值相差不大，而这些值七七八八加起来是84.6G，再加上binlog日志的5个G，就差不多有90个G了，至此数据库容量偏差之谜就算解开了。

参考资料:

本文转自苏幕遮618 51CTO博客，原文链接:http://blog.51cto.com/chenx1242/1947643