数据库的容量很诡异...

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

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

这里外里相差了近乎20个G，那么20个G的差距在哪里呢？

使用show binary logs;看看binlog，算了一下大约5G左右，还是有15G左右的出入。这个出入比较大了，然后记得曾经看过“如果存在对一个 InnoDB 表长时间不结束的查询，而且在查询过程中表有大量的数据变化，则会生成大量的 Undo 信息，导致 ibdata1文件尺寸增加。由于 MySQL 内部机制的限制，ibdata1 文件目前是不支持收缩的。”

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

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

这个时候就又麻烦金山du了一下数据大小的具体分布，如图：

这些值加起来是84.6G，再加上binlog日志的5个G，就差不多有90个G了。由此可见SELECT CONCAT 这个语句根本不准，实际情况要远大于这个值。