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