問題描述

今天轉移數(shù)據(jù)庫（從一個數(shù)據(jù)庫到另一個數(shù)據(jù)庫），轉移了一部分之后發(fā)現(xiàn)硬盤快滿了，于是就把就舊的數(shù)據(jù)庫里已經(jīng)轉移完成的表刪除了。我是先TRUNCATE table_name，發(fā)現(xiàn)空間沒有釋放，又DROP TABLE table_name，發(fā)現(xiàn)空間還是沒有釋放。

我去網(wǎng)上搜了一下，發(fā)現(xiàn)收縮空間的命令都是針對表的，比如OPTIMIZE TABLE table_name。我想請問一下，還有別的辦法收縮空間嗎？

問題解答

InnoDB引擎的特性就是這樣的。占用空間的文件有bin-log文件（二進制日志）和ibdata1(數(shù)據(jù)文件，表空間就是在這里的)還有一些其他日志（ib_logfile0）redo-log和undo-log。

你執(zhí)行TRUNCATE掉了數(shù)據(jù)，并不會對上面這些文件大小產(chǎn)生影響（減?。?，反而會增大，要紀錄你這個TRUNCATE操作。數(shù)據(jù)既使被刪除了，ibdata1空間里也不會被刪除的，因為要刪除里面的數(shù)據(jù)，要移動大量磁盤空間。innodb只是標志那些數(shù)據(jù)頁是可以被再次使用的，并沒有刪除這塊空間。通常mysql一啟動，會會占用幾個G的ibdata1 ibdata2。先分配一塊大的磁盤，再慢慢使用，數(shù)據(jù)在物理上連續(xù)（效率高）。避免一直分配磁盤空間，產(chǎn)生很多碎片。

除非你把整個data數(shù)據(jù)目錄目錄清除（相當于重裝mysql），再重新導入數(shù)據(jù)。

磁盤是很便宜，掛幾塊大磁盤就行了。磁盤都沒有，玩什么數(shù)據(jù)庫。

不了解。但是如果買塊硬盤就能解決問題其實根本沒必要去想其它方案了，投入的綜合成本更高，而且發(fā)生了這種情況本身就說明你們確實要考慮磁盤空間問題了，比如磁盤陣列，數(shù)據(jù)表拆分，是否需要redis/memcached來幫助數(shù)據(jù)庫減壓等，這是更重要的事情。

推薦一下，之前我也遇到過，后來處理了，寫過博客http://astarblog.cn/index.php/2016/04/27/339.html （這算廣告嗎？）