在前三期介紹了RDS for MySQL參數優化，鎖問題以及延遲優化最佳實踐之后，本期將介紹存儲空間相關的最佳實踐。 存儲空間是RDS很重要的一個指標，在RDS的工單問題中，空間問題的咨詢可以排在top 5，當RDS的實際使用空間超過了購買的空間后，實例就會被鎖定了，這樣就會導致應用無法再寫入，更新數據，造成應用的報錯。在RDS的控制臺中可以設定空間的報警閥值，當實例空間到達報警閥值后用戶就會收到報警短信， 這個時候用戶則需要對判斷當前的空間增長是否合理。 如果增長合理則需要對實例的進行彈性升級，這里需要指出的是彈性升級分為兩種： * 本地升降級：該類升級是實例所在的主機磁盤空間充足，足以容納升級所需的空間，這個時候的升級非常迅速，而且對應用毫無影響； * 跨機升級：該類升級時實例所在的主機剩余磁盤空間不足以容納升級所需的空間，那么就需要將實例遷移到其他磁盤資源足夠的主機上，這時需要的時間可能會很長，取決于實例的總空間大小，因為遷移過程涉及將備份拷貝還原到新的主機上，同時還要考慮新實例與舊實例的數據同步問題，那么這一些因素都會導致升級時間較長，最后升級結束時候數據庫中的已有連接會全部斷開（備注：高安全訪問鏈路沒有此問題）。 如果增長不合理，則需要進行快速的判斷問題出現在哪，  也需要我們了解RDS的空間組成到底包括了哪些。在RDS控制臺中可以看到空間的組成分為了5部分，分別為： * 磁盤總空間 * 數據空間 * 日志空間 * 臨時文件空間 * 系統文件空間  接下來我們將一一介紹一下這些文件組成： ## 數據文件 顧名思義該文件空間是指的存放數據的文件，對應到數據庫中就是一張張的表，表的組成主要包括：數據和索引兩類，所以當你看到你的數據文件占用 實例的空間非常多的時候，你需要看一下到底是哪一張表占用了我的空間，用戶可以通過數據庫的數據字典找到系統中占用最大的表： ~~~ select TABLE_SCHEMA,TABLE_NAME,INDEX_LENGTH/1024/1024 as index_M,DATA_LENGTH/1024/1024 as data_M from TABLES order by (INDEX_LENGTH+DATA_LENGTH) desc limit 10; ~~~ 凡事預則立，不預則廢，我們可以未雨綢繆，在設計應用的初期就考慮好系統的存儲： 1. 未來數據的增長趨勢，決定磁盤的空間大小； 2. 數據的生命保留周期，決定是否進行數據刪除或歸檔； 3. 設計表選用合理的數據類型，字段大小，存儲引擎，進行分區還是分表； 下圖的案例中，數據空間占用了實例大量的空間，那么可以通過上述方法定位數據庫中到底是那些張表占用空間導致的問題：  ### 常見的空間問題： 1. 對表進行數據刪除后空間不會進行釋放? 最佳實踐：需要對表進行重建，重建的方法：Optimize table xxxxx，該方法在5.6以下會導致鎖表，RDS 5.6支持在線重建。 2. 大表索引占用的空間比數據空間還大? 最佳實踐：需要將表中無用或者重復的索引刪除，刪除索引需要特別注意該索引是否還在使用。 3. 大表主要用作日志型業務數據存儲，基本都是插入，很少查詢? 最佳實踐：可以使用tokudb引擎將表中的數據進行壓縮，通常壓縮效率在3倍以上，注意使用tokudb引擎需要調整tokudb的buffer， 可參考參數優化loose_tokudb_buffer_pool_ratio。 ## 日志文件： RDS MySQL采用主從M-M的高可用架構，其主備之間的數據同步依靠binlog日志。為了減少binlog日志對用戶的空間的占用，RDS會定時把日志備份到oss中， 然后將本地的binlog清除。當日志空間出現異常的時候，如下圖，由于應用寫入數據壓力過大，導致binlog日志增加的速度大于了RDS上傳到oss的速度， 造成了binlog日志增長迅猛，這時候需要用戶對數據庫進行優化，減小對數據庫的變更操作。  1. 曾經看到這樣的案例，應用頻繁的對表進行更新，但是在該表上有較多的大字段，由于在row格式下，binlog會記錄整行記錄， 這樣就導致了binlog增長非常迅猛，詳細可以參考[Mysql大字段的頻繁更新導致binlog暴增](http://hidba.org/?p=957)。所以在應用的設計初期，就要避免使用大字段：varchar(8000),text,blob,clob等。 2. 還有一種情況可能是主備的復制卡主或者中斷，則會導致主庫的binlog沒有傳遞到備庫，那么這個時候binlog會一直在主庫堆積， 那么就需要提工單要求盡快處理了。 ## 臨時文件： 臨時文件通常可以理解為數據庫做一個大的操作，由于內存不足，數據庫需要將內存中的文件寫到磁盤上，這樣則有可能導致臨時文件寫的非常大， 通常出現這種情況的時候，數據庫在做大的排序操作（order by，group by，distinct）。下圖的案例中，由于數據庫中一條order by的語句頻繁的執行， 但是排序sql沒有索引，導致了臨時文件的頻繁寫操作：  1. 當臨時空間上漲原因是SQL排序導致的時候，可以通過show processlist快速找出排序的SQL，然后kill 掉SQL； 2. 同時對排序的sql添加合適的索引，避免排序，這是治根的辦法，避免數據庫中出現排序的SQL； 3. 為了避免排序消耗的空間過大，可以設置臨時空間的大小，具體可以參考[RDS參數優化loose_rds_max_tmp_disk_space](https://yq.aliyun.com/articles/55594) ## 系統文件： 系統文件是每個數據庫在安裝的時候會初始化一些系統文件，這些系統文件是數據庫正常運行的前提，mysql：ibdata1，ib_logfile0，下面的這幅圖 反映了 “其他文件”占用達到了非常多的問題，可以參考：[ibdata1文件持續增加的問題定位](https://yq.aliyun.com/articles/9055)  1. ibdata1文件中大量的都是undo_log，建議將版本升級到5.6以上有獨立的purge線程可以很快的回收掉undo log，可以單獨設置undo tablespace 文件，避免與ibdata1混用在一起； 2. 同時也可以采用邏輯遷移的方式，重建ibdata1文件； 3. 數據庫中要注意未提交的事務對undo的影響，監控數據庫中的INNODB_TRX視圖。 綜上所述，空間問題也是一個比較復雜的問題，但是如果我們能夠在系統設計之初遵循一些最佳實踐，那么我們還是能夠很好的處理掉這些問題， 祝你玩得開心，用得放心。