如果MySQL磁盤滿了,會發(fā)生什么?還真被我遇到了!
往期熱門文章:
3、花30分鐘,用Jenkins部署碼云上的SpringBoot項目
來源 |?https://urlify.cn/jemaym
使用命令發(fā)現(xiàn)磁盤使用率為100%了,還剩幾十兆。
一系列神操作
備份數(shù)據(jù)庫,刪除實例、刪除數(shù)據(jù)庫表、重啟mysql服務,結果磁盤空間均沒有釋放。
怎么辦
網(wǎng)上查了很多資源,說要進行磁盤碎片化整理。原因是datafree占據(jù)的空間太多啦。具體可以通過這個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。

網(wǎng)上推薦的做法如下所示,對表格進行碎片化整理。
ALTER?TABLE?datainfo?ENGINE=InnoDB;
ANALYZE?TABLE?datainfo;
optimize?table?datainfo;僵局:
查看數(shù)據(jù)庫版本為5.562不支持inodb,要么選擇升級數(shù)據(jù)庫。正在這時,有個不好的消息發(fā)生了,那張表格給刪掉了,但是磁盤空間還是沒有釋放啊。所以對表進行碎片化整理的路也走不通了,因為表沒了。。。
后來的神操作
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.sock2、關閉mysql
service?mysql?stop??3、刪除datadir目錄下的ibdata1、ib_logfile0 ib_logfile1這些文件

4、 移動mysql的啟動參數(shù)
mv?/etc/my.cnf?./abc5、重新啟動mysql 發(fā)現(xiàn)磁盤空間釋放了 service mysql start
磁盤空間終于釋放了
下一步數(shù)據(jù)庫還原
1、采用navicate備份工具,進行數(shù)據(jù)庫備份

備份成功后生成了,生成psc文件。200409141055.psc
2、新建一個數(shù)據(jù)庫實例,設置數(shù)據(jù)庫名和字符集
3、然后對備份數(shù)據(jù)庫進行還原,點擊還原
4、開始進行還原
第一次還原后發(fā)現(xiàn)還原后數(shù)據(jù)庫表建成功了,但是表里面沒有數(shù)據(jù)。后來網(wǎng)上查找資料發(fā)現(xiàn)是,遇到錯誤就停止了。所以更改了還原的配置,再次進行還原。之前是這樣設置的
還原時當成一個事務進行了,遇到錯誤就停止了。更改配置
重新進行還原,數(shù)據(jù)庫里的數(shù)據(jù)有了,并且驗證沒有問題。
問題解決
mysql碎片化產(chǎn)生的原因
(1)表的存儲會出現(xiàn)碎片化,每當刪除了一行內(nèi)容,該段空間就會變?yōu)楸涣艨?,而在一段時間內(nèi)的大量刪除操作,會使這種留空的空間變得比存儲列表內(nèi)容所使用的空間更大;
(2)當執(zhí)行插入操作時,MySQL會嘗試使用空白空間,但如果某個空白空間一直沒有被大小合適的數(shù)據(jù)占用,仍然無法將其徹底占用,就形成了碎片;
(3)當MySQL對數(shù)據(jù)進行掃描時,它掃描的對象實際是列表的容量需求上限,也就是數(shù)據(jù)被寫入的區(qū)域中處于峰值位置的部分;
清除碎片的優(yōu)點:
降低訪問表時的IO,提高mysql性能,釋放表空間降低磁盤空間使用率
注意
1.MySQL官方建議不要經(jīng)常(每小時或每天)進行碎片整理,一般根據(jù)實際情況,只需要每周或者每月整理一次即可(我們現(xiàn)在是每月凌晨4點清理mysql所有實例下的表碎片)。
2.在OPTIMIZE TABLE運行過程中,MySQL會鎖定表。因此,這個操作一定要在網(wǎng)站訪問量較少的時間段進行。
3.清理student的105萬條數(shù)據(jù), OPTIMIZE TABLE 庫.student;本地測試需要37秒。
自測
大家可以用這條語句看看自己的系統(tǒng)的datafree大不大 show table status from 表名;
往期熱門文章:
1、《歷史文章分類導讀列表!精選優(yōu)秀博文都在這里了!》
2、你以為JDK8之后用HashMap就沒事了?死循環(huán)問題依然存在! 3、14 個 Spring MVC 頂級技巧,隨時用隨時爽,一直用一直爽 4、交公糧了:十一在家我都逛了哪些技術網(wǎng)站? 5、高并發(fā)和海量數(shù)據(jù)下的 9 個 Redis 經(jīng)典案例剖析! 6、Docker 禁止被列入美國“實體名單”的國家、企業(yè)、個人使用
7、日志框架到底是Logback 還是 Log4j2? 8、IDEA 2020.2 重磅發(fā)布,動畫級新功能預覽! 9、數(shù)據(jù)庫鏈接池終于搞對了,這次直接從100ms優(yōu)化到3ms! 10、互聯(lián)網(wǎng)公司忽悠員工的黑話,套路太深了。。。
