當發現資料庫的容量很詭異的時候...

今天接收到金山雲的報警郵件，說有一個資料庫出現了容量緊張的情況，我登上控制台一看，如圖：

<a href="https://s4.51cto.com/wyfs02/M02/9B/E9/wKioL1loiCXgGB6SAACXZomq3kM185.png" target="_blank"></a>

然後我登陸mysql client，在指令行裡查詢資料庫的大小卻是得到這樣的值：

<a href="https://s1.51cto.com/wyfs02/M00/9B/E9/wKiom1loiLKwO2BxAABbHpW1Cn8153.png" target="_blank"></a>

再用“select sum(data_length + index_length + data_free) / 1024 / 1024 from information_schema.tables;”這個語句來檢視，結果如圖：

<a href="https://s2.51cto.com/wyfs02/M00/9C/1C/wKiom1lsYLDA5jjpAABGioaANnM807.png" target="_blank"></a>

由于資料檔案在頻繁的 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

<code>SELECT CONCAT(table_schema,</code><code>'.'</code><code>,table_name) AS </code><code>'Table Name'</code><code>,   </code>

<code>    </code><code>table_rows AS </code><code>'Number of Rows'</code><code>,   </code>

<code>    </code><code>CONCAT(ROUND(data_length/(1024*1024*1024),6),</code><code>' G'</code><code>) AS </code><code>'Data Size'</code><code>,   </code>

<code>    </code><code>CONCAT(ROUND(index_length/(1024*1024*1024),6),</code><code>' G'</code><code>) AS </code><code>'Index Size'</code> <code>,   </code>

<code>    </code><code>CONCAT(ROUND((data_length+index_length)/(1024*1024*1024),6),</code><code>' G'</code><code>) AS</code><code>'Total'</code>  

<code>FROM information_schema.TABLES   </code>

<code>WHERE table_schema LIKE </code><code>'要查詢的資料庫名'</code><code>;</code>

效果如下：

<a href="https://s5.51cto.com/wyfs02/M02/9C/1D/wKiom1lsZqPB1ULuAAHEsKIgfps518.png" target="_blank"></a>

然後又麻煩金山方面du了一下資料大小的具體分布，做容量的對比，金山回報的結果如圖：

<a href="https://s1.51cto.com/wyfs02/M02/9B/E9/wKioL1lojV6yJxA2AAAPxHc1w1I046.png" target="_blank"></a>

兩邊的值相差不大，而這些值七七八八加起來是84.6G，再加上binlog日志的5個G，就差不多有90個G了，至此資料庫容量偏差之謎就算解開了。

 本文轉自 蘇幕遮618 51CTO部落格，原文連結:http://blog.51cto.com/chenx1242/1947643