当发现数据库的容量很诡异的时候...-优快云博客

本文通过具体案例解析数据库容量显示与实际占用之间的差异原因，通过对比不同查询方式获得的数据大小，定位到binlog日志文件及未完成的查询任务产生的Undo信息所占空间，最终解决容量偏差问题。

2019独角兽企业重金招聘Python工程师标准>>>

当发现数据库的容量很诡异的时候...

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

然后我登陆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