一.問題描述
我司在某云的MySQL數(shù)據(jù)庫占硬盤空間大于90%，RDS空間總空間為 700G，表A分析之后。某渠道統(tǒng)計的表有5億，單表空間超過350G。
服務(wù)器架構(gòu)：一主多從。
報警截圖：
二.處理流程 1.解決方法一：
鈔能力，增加RDS硬盤空間，劇終！但是會有大表查詢效率問題，數(shù)據(jù)到達(dá)一定量還是需要會出現(xiàn)同樣的問題。
2.解決方法二：
-
備份表A（mysqldump、xtrabackup等）
-
跟研發(fā)溝通，新建相同表結(jié)構(gòu)B，將業(yè)務(wù)數(shù)據(jù)寫入表B中，跑一段時間無問題。【實(shí)際業(yè)務(wù)中，將此表按月分表】
-
截斷表A，釋放硬盤空間（不會導(dǎo)致主從延遲）。
-
定時任務(wù)：定期備份刪除過期數(shù)據(jù)。
涉及到的知識點(diǎn)：
mysql備份（鄙視一下某云，某云備份居然還要收費(fèi)）。
截斷表是否會導(dǎo)致主從延遲（不會）。
表空間分析
mysqldump 備份命令 mysqldump -u 用戶名 -h 數(shù)據(jù)庫地址 -p '密碼' --opt 數(shù)據(jù)庫名 表名 > /data/備份文件名.sql
備份表的時候報錯：
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `XXXXX` at row: 686431
有報錯，于是發(fā)工單，某云客服推薦使用DMS導(dǎo)出
備份的時候影響小部分性能，但是免費(fèi)居然超過免費(fèi)額度。本著能免費(fèi)，為啥要收費(fèi)呢， 真的是無語了，浪費(fèi)幾個小時！
導(dǎo)出失敗: 您當(dāng)前使用的數(shù)據(jù)庫實(shí)例管控模式為“自由操作”，已超出免費(fèi)額度1,000,000。如您需要繼續(xù)操作請調(diào)整實(shí)例管控模式為“穩(wěn)定變更”、“安全協(xié)同”后再進(jìn)行
域名是修改數(shù)據(jù)庫配置，再用mysqldump 將表導(dǎo)出。
于是把這個參數(shù)修改為：
net_read_timeout：288000
net_write_timeout：288000
修改數(shù)據(jù)庫配置
再用mysqldump導(dǎo)出數(shù)據(jù)庫，等了將近十幾個小時之后終于備份成功，大小為193G
mysqldump -u 用戶名 -h 數(shù)據(jù)庫地址 -p '密碼' --opt 數(shù)據(jù)庫名 表名 > /data/備份文件名.sql
新上一張表
實(shí)際在跟研發(fā)溝通，按月來做分表。比如：表名+日期 table_2208
截斷表之后的硬盤總大小
刪除表和截斷表命令之間的區(qū)別
表刪除包括表的定義和關(guān)聯(lián)對象（規(guī)則、索引、約、觸發(fā)器、主鍵，等）。很明顯，一旦表被刪除，那么表中包含的所有的數(shù)據(jù)行都會被一同刪除。
truncate 命令則僅僅刪除了表中所有的數(shù)據(jù)行。表的結(jié)構(gòu)和所有的索引仍然繼續(xù)存在，直到你輸入刪除表的命令（如上所述）。綁定到列上的規(guī)則、默認(rèn)值、約束仍然繼續(xù)綁定，并且觸發(fā)器也仍然起作用。
截斷表命令還會回收所有索引的分配頁。
截斷表的執(zhí)行速度與不帶where子句的delete（刪除）命令相同，甚至比它還要快。delete（刪除） 一次刪除一行數(shù)據(jù)，并且將每一行被刪除的數(shù)據(jù)都作為一個事務(wù)記錄日志；而truncate （截斷）表則回收整個數(shù)據(jù)頁，只記錄很少的日志項。delete（刪除）和truncate（截斷）都會回收被數(shù)據(jù)占用的空間，以及相關(guān)的索引。只有表的擁有者可以截斷表。
