用戶在使用 MySQL 實例時，會遇到空間使用告警甚至超過實例限額被鎖定的情況。在 RDS 控制台的實例基本信息中，即會出現如下信息：
本文將介紹造成空間使用率過高的常見原因及其相應的解決方法。對於MySQL 5.6版本的實例，升級實例規格和存儲空間后即可解鎖實例，關於如何升級實例配置，請參見變更配置。
常見原因
造成 MySQL 實例空間使用率過高，主要有如下四種原因：
-
Binlog 文件占用高。
-
數據文件占用高。
-
臨時文件占用高。
-
系統文件占用高。
查看空間使用狀況
您可以通過 DMS 中的診斷報告來查看實例空間的使用情況。
-
在 DMS 控制台上登錄數據庫。
-
選擇性能 > 診斷報告。
-
單擊發起診斷，即可創建一個針對當前實例運行情況的報告，如下圖所示：
-
單擊查看報告，即可在診斷報告中查看到實例空間使用情況，如下圖所示：
圖示說明：
-
ins_size：實例整體空間。
-
other_size：系統文件和臨時文件使用空間。
-
data_size：數據文件使用空間。
-
binlog_size - Binlog：文件占用空間。
-
解決方法
升級實例規格
升級實例規格是解決空間問題的有效方式之一。目前，RDS已支持獨占物理機規格的實例，最大存儲空間可達到3T。建議您將實例規格升級至獨占物理機，關於獨占物理機實例的計費詳情，請參見雲數據庫RDS詳細價格信息，升級實例規格的操作步驟如下。
-
登錄RDS管理控制台。
-
選擇目標實例所在地域。
-
單擊目標實例的ID，進入基本信息頁面。
-
在配置信息欄中，單擊變更配置。
說明：若是包年包月實例，請再單擊立即升級配置或者續費降配/續費升配。
-
在變更實例頁面，將實例規格變更為獨占物理機，並選擇較大的存儲空間，如下圖所示。
-
單擊確認變更。
其它方法
本章節將介紹在不升級實例規格的情況下解決空間問題的方法。
Binlog 文件占用高的解決方法
Binlog 文件記錄實例的事務信息，是 MySQL 實例 HA 架構以及高可用性、可恢復性的基礎，是不可以關閉的。
RDS 實例會以一定時間間隔自動清理（上傳到 OSS 並從實例空間中刪除）最近 18 小時外的 Binlog 文件。如果短時間內實例 DML 操作生成了大量 Binlog 數據，有可能會導致超過實例磁盤空間上限而被鎖定。
在這種情況下，可以通過 RDS 控制台來清理（將 Binlog 文件上傳到 OSS 並從實例空間中刪除）Binlog 數據。
操作步驟
-
登錄 RDS 管理控制台。
-
選擇目標實例所在地域。
-
單擊目標實例的 ID，進入基本信息頁面。
-
選擇左側菜單欄中的備份恢復。
-
單擊一鍵上傳 Binlog。
說明：
-
一鍵上傳 Binlog 會在后台異步提交清理任務，因此單擊后會很快返回。清理任務會先將完成寫入的 Binlog 上傳到 RDS 的 OSS （非用戶購買的 OSS）上，然后再從實例空間中刪除 Binlog 文件，當前正在被寫入的 Binlog 文件由於未完成寫入，是不可以被清理的。因此，清理過程會有一定延遲，建議您單擊后耐心等待一定時間，請勿多次單擊該按鈕。
-
對於由於 DML 等操作（比如涉及大字段的 DML 操作）導致快速生成 Binlog 的情況，可能會出現多次單擊一鍵上傳 Binlog 按鈕但 Binlog 空間占有率依舊上漲的情況，這是因為上傳 Binlog 文件到備份空間並且從實例空間中刪除的處理速度跟不上實例生成 Binlog 文件的速度，在這種情況下，建議考慮升級磁盤空間，並且排查 Binlog 快速生成的原因。
-
數據文件占用高的解決方法
對於數據文件占用空間高的情況，可以通過清理數據的方式來減少空間占用情況，比如通過 drop table 和 truncate table 命令來清理不再需要的數據。
另外，下面是兩種用戶常用於清除空間內數據文件的方法，但實際並為達到預期效果，原因及解決方法如下所示：
-
用
delete操作刪除數據delete操作不能夠直接回收被刪除數據占用的數據文件空間，這就好比排空泳池中的水但泳池的占地面積不會發生改變一樣。在用
delete操作刪除數據后，需要通過optimize table tab_name;操作來回收空間，詳情請參見 RDS for MySQL 刪除數據后顯示空間沒有減少。 -
刪除備份
RDS 備份是放置在后台 OSS 上，不占用用戶的 RDS 實例空間，因此刪除備份不能解決實例的空間問題。而且刪除備份會影響實例的可恢復性，強烈建議在任何情況下都不要考慮刪除備份。
數據文件占用空間的查詢方法
方法一：
數據文件在頻繁的 DML 后會出現數據空洞的現象，通過如下查詢獲取的數據文件占用的空間比較接近實際數據文件占用空間的計算方式：
select sum(data_length + index_length + data_free) / 1024 / 1024 from information_schema.tables;
方法二：
information_schema.tables 提供的是根據采樣獲取的表的部分統計信息，因此通過如下查詢獲取的表、庫數據尺寸和實際數據文件占用尺寸間會有出入（通常要小於實際數據文件占用空間）。
說明：因為 information_schema.tables 中提供的是采樣統計數據，因此該計算方式在統計數據比較接近實際的情況下，才會比較接近真實空間占用情況。
select table_name, concat(round((data_length + index_length) / 1024 / 1024,2),’MB’)from information_schema.tableswhere table_schema = ‘rd_test’and table_name = ‘large_tab_01’;
查詢結果如下圖所示：
從上圖可以看出，在收集表的統計信息前后反饋出的表數據量大小存在差異。即使通過 analyze table 命令重新收集統計信息，得到的數值通常也小於實際數據文件占用空間，例如本例的 16143 MB 也小於該表的數據文件實際占用的空間。
臨時文件占用高的解決方法
臨時文件會隨查詢的結束或者會話的終止而自動釋放，因此如果是臨時文件導致實例空間滿而鎖定，可以通過終止會話來釋放空間。
關於如何終止會話，請參見 RDS for MySQL 如何終止會話。
關於臨時文件的常見問題，請參見 RDS for MySQL the table ‘/home/mysql/xxxx/xxxx/#tab_name’ is full 的原因和處理。
https://help.aliyun.com/knowledge_detail/51682.html
系統文件占用高的解決方法
系統文件涉及到 ibdata1 系統表的空間文件和 ib_logfile0、ib_logfile1 日志文件。
ibdata1 文件
InnoDB 引擎表由於支持多版本並發控制（MVCC），因此會將查詢所需的 Undo 信息保存在系統文件 ibdata1 中。
如果存在對一個 InnoDB 表長時間不結束的查詢，而且在查詢過程中表有大量的數據變化，則會生成大量的 Undo 信息，導致 ibdata1 文件尺寸增加。由於 MySQL 內部機制的限制，ibdata1 文件目前是不支持收縮的。
因此，若出現這種情況，在不升級磁盤空間的前提下，比較好的解決方法是在同地域同可用區購買相同配置的 RDS 實例，通過 DTS 工具將數據遷移到新實例中。
建議您監控和清理執行時間過長的會話或事務，詳情請參見 RDS MySQL 管理長時間運行查詢。
ib_logfile 日志文件
ib_logfile0 和 ib_logfile1 日志文件保存 InnoDB 引擎表的事務日志信息，其文件大小尺寸固定，不可以改變。較大的尺寸在高並發事務的場景下有利於減少事務日志文件切換的次數，提高實例性能。