今天接收到金山雲的報警，說有一個數據庫出現了容量報警，我登上控制臺一看，如圖：

然後我登陸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 這個語句根本不準，實際情況要遠大於這個值。

本文出自 “生活就是等待戈多” 博客，請務必保留此出處http://chenx1242.blog.51cto.com/10430133/1947643

數據庫的容量很詭異...