資訊專欄INFORMATION COLUMN
適用場景
如果數據庫里有一張大于1T的表需要刪除，那么用什么方法操作最安全呢？所謂的安全，即為刪除過程中，不影響數據庫的響應，業(yè)務連接不會卡殼，系統正常使用……
假如直接登錄數據庫使用drop table tablename;會是什么情況？在drop table的時候，innodb會維護一個全局鎖，drop完畢鎖才能釋放。這就意味著，在白天，訪問量非常大的時候，執(zhí)行刪除大表的命令，整個mysql就會掛起，在刪表期間，QPS也會嚴重下滑，后果可想而知……
最佳選擇（原理）
正確的方法為使用linux下硬鏈接的知識，進行大表刪除，對數據庫自身的健康度影響較小。
所謂的硬鏈接，就是不止一個文件名指向node Index，有好幾個文件名指向node Index。
假設，又有一個文件名指向上面的node Index，如下：
這時，如果做了刪除文件名(1)的操作，linux系統檢測到，還有一個文件名(2)指向node Index，因此并不會真正的把文件刪了，而是把文件(1)的引用給刪了，這步操作非常快，只是刪除引用。于是就會變成如下:
接下來，如果再刪除文件名(2)的操作，linux系統檢測到，沒有其他文件名指向該node Index，就會刪除真正的存儲文件，這步操作，是刪真正的文件，所以會比較慢。這時，我們寫一個for循環(huán)，進行小量文件，多次刪除，直到大文件變小，安全了，才從磁盤上RM。
環(huán)境說明
雙主架構：192.168.157.50：30016，192.168.157.51：30016
實例名字：xxx_test
刪除大表：xxx.alipay_fans，大小為30GB
文件路徑：/data/mysql/db_xxx_test/data/xxx/Alipay_fans.ibd
操作步驟
在50主機上：
在51主機上：
只在主庫50上操作，drop后只剩下bbk的硬鏈接。
查看51上的文件情況，同主庫一樣，只剩下bbk的硬鏈接。
在50主機上操作：
在51主機上操作：
操作完成后，主從狀態(tài)正常，數據庫狀態(tài)正常。
#filename=/data/mysql/db_xxx_test/data/xxx/alipay_fans.ibd
#filesize=30 #定義要刪除文件的大小，單位GB（以實際大小調整）
#ln $filename $filename.bbk
# for i in `seq $filesize -1 1`;do truncate -s ${i}G $filename.bbk;ll -h $filename.bbk;done
#rm $filename.bbk
備注：從文件大小30G開始，每次縮減1G，執(zhí)行truncate，直到文件剩余1G，最后使用rm命令刪除剩余的部分。
更多精彩干貨分享
點擊下方名片關注
IT那活兒
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/129779.html
摘要：也就是說當使用字符型存儲數據后，該數據轉換為二進制時的長度超過了位，那么該數據將不會完整存儲，會丟失一部分數據。 showImg(https://segmentfault.com/img/bVbuYxg?w=3484&h=2480); 閱讀本文大約需要 8 分鐘。 寫在前面 數據庫打算只寫 MySQL，Redis 兩部分，不會很細，主要以面試題為主。這次寫的是 MySQL 篇。 1.說...
摘要：步優(yōu)化以及其它數據庫后端掘金原文鏈接在發(fā)表了一篇簡潔有效有趣和令人信服的分鐘教程描述了如何進行優(yōu)化。關于的七種后端掘金對于的，在學習起來可能是比較亂的。 5 步優(yōu)化 MongoDB 以及其它數據庫 - 后端 - 掘金原文鏈接 Jared Rosoff 在 Scale Out Camp 發(fā)表了一篇簡潔、有效、有趣和令人信服的《8 分鐘 MongoDB 教程》描述了如何進行 MongoDB...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20
