問題

使用命令發(fā)現(xiàn)磁盤使用率為100%了，還剩幾十兆。

一系列神操作

備份數(shù)據(jù)庫，刪除實(shí)例、刪除數(shù)據(jù)庫表、重啟mysql服務(wù).結(jié)果磁盤空間均未釋放

怎么辦

網(wǎng)上查了很多資源，說要進(jìn)行磁盤碎片化整理。原因是datafree占據(jù)的空間太多啦。具體可以通過這個(gè)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';

?

這個(gè)是后來的圖了，之前的圖沒有留，當(dāng)時(shí)顯示一張表里的data_free都達(dá)到了20個(gè)G。

網(wǎng)上推薦的做法如下所示，對表格進(jìn)行碎片化整理。

?

ALTER?TABLE?datainfo?ENGINE=InnoDB;
ANALYZE?TABLE?datainfo;

optimize?table?datainfo;

?

僵局

查看數(shù)據(jù)庫版本為5.562不支持inodb，要么選擇升級數(shù)據(jù)庫。正在這時(shí)，有個(gè)不好的消息發(fā)生了，那張表格給刪掉了，但是磁盤空間還是沒有釋放啊。所以對表進(jìn)行碎片化整理的路也走不通了，因?yàn)楸頉]了。。。

后來的神操作

使用命令查看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

?

關(guān)閉mysql

?

service?mysql?stop　　

?

刪除datadir目錄下的ibdata1、ib_logfile0 ib_logfile1這些文件

#FormatImgID_1#

移動mysql的啟動參數(shù)

?

mv?/etc/my.cnf?./abc

?

重新啟動mysql 發(fā)現(xiàn)磁盤空間釋放了

?

service?mysql?start

?

磁盤空間終于釋放了

下一步數(shù)據(jù)庫還原

采用navicate備份工具，進(jìn)行數(shù)據(jù)庫備份

備份成功后生成了，生成psc文件200409141055.psc。

新建一個(gè)數(shù)據(jù)庫實(shí)例，設(shè)置數(shù)據(jù)庫名和字符集

然后對備份數(shù)據(jù)庫進(jìn)行還原，點(diǎn)擊還原

開始進(jìn)行還原

第一次還原后發(fā)現(xiàn)還原后數(shù)據(jù)庫表建成功了，但是表里面沒有數(shù)據(jù)。后來網(wǎng)上查找資料發(fā)現(xiàn)是，遇到錯(cuò)誤就停止了。所以更改了還原的配置，再次進(jìn)行還原。
之前是這樣設(shè)置的

還原時(shí)當(dāng)成一個(gè)事務(wù)進(jìn)行了，遇到錯(cuò)誤就停止了。更改配置

重新進(jìn)行還原，數(shù)據(jù)庫里的數(shù)據(jù)有了，并且驗(yàn)證沒有問題。

問題解決

mysql碎片化產(chǎn)生的原因

表的存儲會出現(xiàn)碎片化，每當(dāng)刪除了一行內(nèi)容，該段空間就會變?yōu)楸涣艨?，而在一段時(shí)間內(nèi)的大量刪除操作，會使這種留空的空間變得比存儲列表內(nèi)容所使用的空間更大；

當(dāng)執(zhí)行插入操作時(shí)，MySQL會嘗試使用空白空間，但如果某個(gè)空白空間一直沒有被大小合適的數(shù)據(jù)占用，仍然無法將其徹底占用，就形成了碎片；

當(dāng)MySQL對數(shù)據(jù)進(jìn)行掃描時(shí)，它掃描的對象實(shí)際是列表的容量需求上限，也就是數(shù)據(jù)被寫入的區(qū)域中處于峰值位置的部分；

清除碎片的優(yōu)點(diǎn)

降低訪問表時(shí)的IO,提高mysql性能,釋放表空間降低磁盤空間使用率

MySQL官方建議不要經(jīng)常(每小時(shí)或每天)進(jìn)行碎片整理，一般根據(jù)實(shí)際情況，只需要每周或者每月整理一次即可(我們現(xiàn)在是每月凌晨4點(diǎn)清理mysql所有實(shí)例下的表碎片)。

在OPTIMIZE TABLE運(yùn)行過程中，MySQL會鎖定表。因此，這個(gè)操作一定要在網(wǎng)站訪問量較少的時(shí)間段進(jìn)行。

清理student的105萬條數(shù)據(jù), OPTIMIZE TABLE 庫.student;本地測試需要37秒。

自測

大家可以用這條語句看看自己的系統(tǒng)的datafree大不大