このページでは、ディスク使用率が高いことがわかっている問題について説明し、トラブルシューティングのヒントを紹介します。
ディスク使用率が高いことがわかっている問題は次のとおりです。
- 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 |
ibdata* ファイルで構成される InnoDB システム テーブルスペースで使用されるストレージ。 |
Last_sys_tablespace |
最新のテーブルスペースで使用されているストレージ。 |
Others |
内部システム ファイルが含まれます。 |
Redo_log |
クラッシュリカバリーに使用される InnoDB の REDO ログで使用されるストレージ。 |
Relaylog |
レプリケーション中にレプリカ インスタンスのリレーログで使用されるストレージ。 |
Slow_log |
低速のクエリログが有効になっていて、ディスクに保存されている場合に使用されるストレージ。 |
Temporary files |
MySQL によって作成された一時ファイルのストレージを明示的に追跡します。 |
Temporary_space |
/tmp ディレクトリ内のオペレーティング システムの一時ファイルで使用されるストレージ。 |
Tmp_data |
並べ替えや結合などのオペレーション中に MySQL によって作成された一時データ。 |
Undo_log |
取り消しログで使用されるストレージ。 |
Temporary_files カテゴリと Others カテゴリのファイルを検索する
長時間実行されるクエリ（複雑な JOIN、ORDER BY、GROUP BY オペレーションなど）は、MySQL ディレクトリに大きな一時ファイルを作成します。
2026 年 4 月以降にリリースされたメンテナンス バージョンを使用する MySQL インスタンスの場合、これらの一時ファイルは Temporary_files カテゴリに明示的に報告されます。
以前のバージョンでは、一時ファイルは Others カテゴリに報告されます。
ディスク使用率が高い場合のトラブルシューティング
大きな一時ファイルが原因でディスク使用率が高くなる問題のトラブルシューティングを行う手順は次のとおりです。
アクティブな長時間実行クエリを特定する
ディスク使用率が高い問題は、長時間実行されるクエリ（複雑な JOIN、ORDER BY、GROUP BY オペレーションなど）が MySQL ディレクトリに大量の一時ファイルを作成することが原因で発生することがほとんどです。これらの一時ファイルは、Temporary_files または Others のカテゴリに分類されます。
新しいメンテナンス バージョン（バージョン r20260320.00_00 以降）の MySQL インスタンスには、実行時間の長いクエリによって作成され、MySQL によってリンク解除された（つまり、ファイルは存在するが、MySQL プロセスにリンクされていない）一時ファイルを示すテーブル INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES があります。
次のクエリを使用して、アクティブな長時間実行クエリを取得します。
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 値を取得できます。以前のバージョン（バージョン
r20260117以前）の場合、SHOW FULL PROCESSLISTオペレーションの出力から PROCESS_ID 値を取得できます。
一時ファイルによるディスク使用量の増加の原因となったクエリが終了した後、ディスク使用量の指標にこれらの変更が登録されるまでに最大で約 5 分かかることがあります。
Query Insights を使用する
パフォーマンスの低いクエリを特定して改善するには、クエリ分析情報を使用することをおすすめします。
詳細については、Query Insights を使用してクエリのパフォーマンスを向上させるをご覧ください。
振り返り分析を行う
使用率の急増が収まったら、次の方法で過去のデータを分析して原因を特定できます。
Query Insights。大きな一時ファイルを作成した可能性のあるクエリを確認します。クエリ ダイジェスト別にリストされたクエリ（平均実行時間、クエリ数、スキャンおよび返された平均行数などの指標を含む）を調べます。
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: 履歴リストの長さが長くなる原因として、長時間実行されているトランザクションが undo ログの削除をブロックしていることが考えられます。これは、ディスク使用量の問題の原因にもなります。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 インスタンスをモニタリングするをご覧ください。