今天接收到金山云的报警邮件，说有一个数据库出现了容量紧张的情况，我登上控制台一看，如图：
然后我登陆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的情况，使用语句：
|
1
2
3
4
5
6
7
|
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了，至此数据库容量偏差之谜就算解开了。
参考资料:https://linux.cn/article-5829-rss.html
参考资料: http://blog.chinaunix.net/uid-24373487-id-4223322.html
