本頁說明已知的高磁碟用量問題，並提供疑難排解協助。
已知的高磁碟用量問題包括：
- MySQL 8.0 以上版本大量使用
Temporary_files檔案。 - MySQL 8.0 和更早版本大量使用
Others檔案。
在 MySQL 8.0 之前的版本中，暫存檔案用量會歸類在 tmp_data 檔案下。
MySQL 儲存空間細目指標
用來監控詳細磁碟用量的主要指標是 cloudsql.googleapis.com/database/disk/bytes_used_by_data_type。這項指標會提供執行個體磁碟用量的詳細資料，按照資料類型分類，如下所示：
| 資料類型 | 定義 |
|---|---|
Binlog |
MySQL 二進位記錄檔使用的儲存空間，這是時間點復原和複製作業的必要條件。 |
Cloudsql_mysql_audit_log |
Cloud SQL MySQL 稽核記錄使用的儲存空間。 |
Data |
包括主要 InnoDB 表格空間 (.ibd 檔案) 和系統表格空間 (ibdata1)。 |
General_log |
一般查詢記錄使用的儲存空間。 |
General_tablespace |
InnoDB 系統表空間使用的儲存空間，由 ibdata* 檔案組成。 |
Last_sys_tablespace |
最新表空間使用的儲存空間。 |
Others |
包括內部系統檔案。 |
Redo_log |
用於當機復原的 InnoDB 重做記錄所用的儲存空間。 |
Relaylog |
複本執行個體在複製期間使用的中繼記錄儲存空間。 |
Slow_log |
如果啟用慢速查詢記錄並儲存在磁碟上，則慢速查詢記錄使用的儲存空間。 |
Temporary files |
MySQL 建立的暫存檔案所使用的儲存空間。 |
Temporary_space |
作業系統暫存檔案在 /tmp 目錄中使用的儲存空間。 |
Tmp_data |
MySQL 在排序和聯結等作業期間建立的暫時資料。 |
Undo_log |
復原記錄使用的儲存空間。 |
找出「Temporary_files」和「Others」類別中的檔案
長時間執行的查詢 (例如複雜的 JOIN、ORDER BY 或 GROUP BY 作業) 會在 MySQL 目錄中建立大型臨時檔案。
如果 MySQL 執行個體使用 2026 年 4 月起發布的維護版本，系統會明確將這些暫時檔案歸類在 Temporary_files 類別下。
在舊版中，系統會將暫時性檔案歸類在 Others 類別。
排解磁碟使用率偏高的問題
如要排解大型暫時檔案造成磁碟使用率過高的問題，請按照下列步驟操作：
找出長時間執行的查詢
長時間執行的查詢 (例如複雜的 JOIN、ORDER BY 或 GROUP BY 作業) 會在 MySQL 目錄中建立大量臨時檔案，導致磁碟使用率過高。這些暫時性檔案會歸類在 Temporary_files 或 Others 類別下。
如果 MySQL 執行個體使用新的維護版本 (版本 r20260320.00_00 以上)，您可以在 INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES 資料表中查看由長時間執行的查詢建立，且未連結的暫時檔案 (也就是檔案存在，但未連結至 MySQL 程序)。
使用下列查詢取得執行中的長時間執行查詢：
SELECT
otf.fd, otf.size, p.id, p.info, p.user
FROM
INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES otf
LEFT JOIN
performance_schema.processlist p
ON
otf.SESSION_ID = p.ID;
輸出內容範例：
+----+------------+------+----------------------------------+------+
| fd | size | id | info | user |
+----+------------+------+----------------------------------+------+
| 39 | 1670750208 | 8 | select * from t1 order by rand() | root |
| 40 | 1670750208 | 8 | select * from t1 order by rand() | root |
+----+------------+------+----------------------------------+------+
2 rows in set (0.00 sec)
如要取得維護版本為 r20260320.00_00 以下的執行個體中長時間執行的有效查詢，請使用下列查詢：
SHOW FULL PROCESSLIST;
在輸出內容中，找出通常會使用磁碟暫存檔案的作業：
- 大型
JOIN作業，尤其是沒有適當索引的情況。 - 對大型結果集執行複雜的
ORDER BY或GROUP BY作業。 - 大型
ALTER TABLE作業。
立即緩解
如果調查結果顯示某項執行中的查詢是磁碟空間用盡的原因，您可以終止該查詢，釋出相關的暫存檔空間。
如要終止查詢，請執行下列指令：
KILL PROCESS_ID;
將 PROCESS_ID 替換為查詢的程序 ID：
如果是
r20260320以上的維護版本，您可以透過INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES資料表的 SESSION_ID 資料欄擷取 PROCESS_ID 值。如果是較舊版本 (
r202601172.0.0 或更早版本)，您可以從SHOW FULL PROCESSLIST作業的輸出內容擷取 PROCESS_ID 值。
如果查詢導致磁碟用量增加 (透過暫時檔案)，查詢終止後，磁碟用量指標最多可能需要約 5 分鐘才會反映這些變更。
使用查詢洞察
建議您使用查詢洞察功能，找出並改善效能不佳的查詢。
詳情請參閱「使用查詢洞察提升查詢效能」。
執行回顧分析
用量尖峰期過後，您可以分析歷來資料，找出原因：
查詢洞察。檢查是否有查詢作業可能建立了大型暫存檔案。依查詢摘要檢查列出的查詢 (包括平均執行時間、查詢數，以及掃描和傳回的平均資料列數等指標)。
Slow_log。啟用Slow_log並將long_query_time設為適當的門檻。這份記錄會擷取長時間執行的查詢，以供分析及最佳化。General_log。檢查General_log(如已啟用)，找出事件期間記錄的查詢，這些查詢可能含有JOIN或SORT作業，並可能產生大型暫時檔案。否則，您可以啟用General_log，並在下一個這類事件中擷取查詢。Cloud Monitoring 指標。查看下列指標：
cloudsql.googleapis.com/database/mysql/tmp_disk_tables_created_count： 追蹤在磁碟上建立的暫時資料表數量，這通常是大型未連結檔案的原因。cloudsql.googleapis.com/database/mysql/handler_operations_count： 追蹤該時間前後的作業數量增加情形。cloudsql.googleapis.com/database/mysql/innodb/active_trx_total_time： 追蹤長時間有效的交易。
如果這些指標在磁碟用量尖峰時段有所增加，強烈表示產生大型暫存資料表的查詢是根本原因。
交易記錄。查看下列指標：
cloudsql.googleapis.com/database/mysql/innodb/history_list_length metric： 如果長時間執行的交易封鎖復原記錄清除作業，可能會導致記錄清單長度過長，進而造成磁碟用量問題。cloudsql.googleapis.com/database/mysql/innodb/active_trx_longest_time： 磁碟用量偏高期間的長時間交易。
最佳化查詢
記錄分析找出導致指標尖峰的特定查詢後，您可以進行最佳化或重寫查詢，盡量減少產生大量暫時檔案。
如要最佳化查詢，可以採取下列做法：
- 新增適當的索引。
- 重構複雜的聯結或排序作業。
詳情請參閱「查詢調整」。
設定監控和快訊
為避免日後因磁碟用量不受控而發生事件 (尤其是長時間執行的查詢所產生的暫時性檔案)，請使用 Monitoring 實作主動監控和警報。
您可以針對指標建立警告，指出資源耗用量過高，或是查詢模式會產生大量暫時檔案。
| 指標名稱 | 說明 | 建議的警告門檻 |
|---|---|---|
cloudsql.googleapis.com/database/disk/utilization |
已使用的磁碟空間百分比。
這項指標會監控整體磁碟容量使用情況。 |
> 80% (持續超過 5 分鐘) |
cloudsql.googleapis.com/database/disk/bytes_used |
資料庫執行個體使用的磁碟空間總位元組數。
這項指標會追蹤磁碟消耗量的絕對成長。 |
根據「database/disk/quota」指標監控。 |
如要瞭解如何設定 Cloud SQL 指標的快訊和監控功能，請參閱「快訊總覽」和「監控 Cloud SQL 執行個體」。