如果 MySQL磁盤滿了，會發生什么？還真被我遇到了
使用命令發現磁盤使用率為100%了，還剩幾十兆。
一系列神操作
備份數據庫，刪除實例、刪除數據庫表、重啟mysql服務，結果磁盤空間均沒有釋放。
怎么辦
網上查了很多資源，說要進行磁盤碎片化整理。原因是datafree占據的空間太多啦。具體可以通過這個sql查看。
- SELECT CONCAT(TRUNCATE(SUM(data_length)/1024/1024,2),'MB') AS data_size,
- CONCAT(TRUNCATE(SUM(max_data_length)/1024/1024,2),'MB') AS max_data_size,
- CONCAT(TRUNCATE(SUM(data_free)/1024/1024,2),'MB') AS data_free,
- CONCAT(TRUNCATE(SUM(index_length)/1024/1024,2),'MB') AS index_size
- FROM information_schema.tables WHERE TABLE_NAME = 'datainfo';
這個是后來的圖了，之前的圖沒有留，當時顯示一張表里的data_free都達到了20 個G。
網上推薦的做法如下所示，對表格進行碎片化整理。
- ALTER TABLE datainfo ENGINE=InnoDB;
- ANALYZE TABLE datainfo;
- optimize table datainfo;
僵局：
查看數據庫版本為5.562不支持inodb，要么選擇升級數據庫。正在這時，有個不好的消息發生了，那張表格給刪掉了，但是磁盤空間還是沒有釋放啊。所以對表進行碎片化整理的路也走不通了，因為表沒了。。。
后來的神操作
1、使用命令查看mysql安裝的位置和配置文件所在的地方
- mysql 1118 945 0 14:28 ? 00:00:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
2、關閉mysql
- service mysql stop
3、刪除datadir目錄下的ibdata1、ib_logfile0 ib_logfile1這些文件
4、 移動mysql的啟動參數
- mv /etc/my.cnf ./abc
5、重新啟動mysql 發現磁盤空間釋放了
- service mysql start
磁盤空間終于釋放了
下一步數據庫還原
1、采用navicate備份工具，進行數據庫備份
備份成功后生成了，生成psc文件。200409141055.psc
2、新建一個數據庫實例，設置數據庫名和字符集
3、然后對備份數據庫進行還原，點擊還原
4、開始進行還原 第一次還原后發現還原后數據庫表建成功了，但是表里面沒有數據。
后來網上查找資料發現是，遇到錯誤就停止了。所以更改了還原的配置，再次進行還原。之前是這樣設置的。
還原時當成一個事務進行了，遇到錯誤就停止了。更改配置。
圖片重新進行還原，數據庫里的數據有了，并且驗證沒有問題。
問題解決
mysql碎片化產生的原因
（1）表的存儲會出現碎片化，每當刪除了一行內容，該段空間就會變為被留空，而在一段時間內的大量刪除操作，會使這種留空的空間變得比存儲列表內容所使用的空間更大；
（2）當執行插入操作時，MySQL會嘗試使用空白空間，但如果某個空白空間一直沒有被大小合適的數據占用，仍然無法將其徹底占用，就形成了碎片；
（3）當MySQL對數據進行掃描時，它掃描的對象實際是列表的容量需求上限，也就是數據被寫入的區域中處于峰值位置的部分。
清除碎片的優點:
降低訪問表時的IO,提高mysql性能,釋放表空間降低磁盤空間使用率。
注意
1.MySQL官方建議不要經常(每小時或每天)進行碎片整理，一般根據實際情況，只需要每周或者每月整理一次即可(我們現在是每月凌晨4點清理mysql所有實例下的表碎片)。
2.在OPTIMIZE TABLE運行過程中，MySQL會鎖定表。因此，這個操作一定要在網站訪問量較少的時間段進行。
3.清理student的105萬條數據, OPTIMIZE TABLE 庫.student;本地測試需要37秒。
自測
大家可以用這條語句看看自己的系統的datafree大不大 show table status from 表名;
