問題描述
阿里雲雲資料庫RDS MySQL執行個體由於臨時檔案佔用磁碟空間較多，導致執行個體的運行狀態為“鎖定中”。RDS MySQL執行個體（執行個體ID：rm-***xez）的運行狀態顯示為鎖定中。該執行個體配置為MySQL 5.7、2核CPU、最大串連數1200，地區為華北5（呼和浩特），建立時間為2021年8月11日。
問題原因
MySQL執行個體可能會由於查詢語句的排序、分組、關聯表產生的暫存資料表檔案，或者大事務未提交前產生的binlog cache檔案，導致執行個體磁碟空間滿。為避免資料丟失，RDS會將執行個體鎖定，在鎖定之後，將無法進行寫入操作。
解決方案
在緊急情況下建議擴容執行個體儲存空間，擴容後需要耐心等待一段時間（5分鐘左右），方可解鎖執行個體，關於如何升級執行個體配置，請參見變更配置。
若您無法擴容執行個體儲存空間，根據版本不同按照以下方法處理：
-
MySQL 5.7及以下大版本：重啟執行個體。
-
MySQL 8.0大版本：鎖定時會結束所有使用者會話，會話被結束後會自動開始復原，復原根據當時正在執行的查詢不同需要消耗不同的時間，執行個體空間會在交易回復完成後自行釋放。
如果長時間不能自動解鎖，請參考以下操作處理：
-
通過DMS串連執行個體。
-
執行以下SQL語句，查看資料庫的會話。
show processlist -
單擊顯示結果中的State，進行狀態排序，在狀態列查看是否有大量“Copy to tmp table”、“Sending data”等資訊，然後記錄該會話的ID值。執行結果返回進程列表，包含 Id、User、Host、db、Command、Time、State 列，可根據 Command 和 State 列定位異常會話（如 State 為 Copy to tmp table、Sending data 的會話）。
-
執行以下SQL語句，終止會話。
kill [$ID];說明[$ID]為上一步擷取的ID值，注意確認終止該會話不會影響業務。
-
後續維護
若鎖定問題已解決，請參考以下步驟，預防再次出現鎖定問題：
-
在資源不足時，執行個體自動擴容儲存空間，詳情請參見設定儲存空間自動擴容。
-
針對查詢產生的臨時檔案，應該最佳化SQL語句，避免頻繁使用order by、group by操作，可以適當的將tmp_table_size和max_heap_table_size值調大，但是為了減少磁碟使用而調高tmp_table_size和max_heap_table_size並不明智，因為記憶體資源遠比磁碟資源寶貴。您可以通過explain加SQL語句查看是否使用內部暫存資料表，樣本如下，在Extra欄位中有“Using temporary”字樣，則代表會使用內部暫存資料表。
explain select * from alarm group by created_on order by default;系統顯示類似如下。執行結果中
type值為ALL表示全表掃描，Extra列除Using temporary外還包含Using filesort，表明查詢同時存在檔案排序。 -
針對binlog cache，應該減少執行大事務的情況，尤其應該減少在多個串連同時執行大事務的情況，如果大事務比較多，可以適當將binlog_cache_size值調大，但是同樣不建議為了節省磁碟空間調整這個參數，建議使用短串連執行大事務，降低臨時空間開銷。
-
建議您監控磁碟使用率，及時清理資料或進行資料拆分，使磁碟使用率不超過80%。
更多資訊
若您暫時無法清理臨時檔案進行解鎖，您可以清理其他類型的檔案，降低磁碟空間使用率，如下所示：