本页面介绍了已知的磁盘用量过高问题，并提供了问题排查帮助。
已知的高磁盘用量问题包括：
- 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 目录中创建大型临时文件。
对于使用 2026 年 4 月起发布的维护版本的 MySQL 实例，这些临时文件会在 Temporary_files 类别下明确报告。
在早期版本中，临时文件会在 Others 类别下报告。
排查磁盘用量过高的问题
如需排查因大型临时文件导致的高磁盘用量问题，请按照以下步骤操作：
识别活跃的长时间运行的查询
磁盘用量过高的问题通常是由长时间运行的查询（例如复杂的 JOIN、ORDER BY 或 GROUP BY 操作）在 MySQL 目录中创建大量临时文件引起的。这些临时文件归入 Temporary_files 或 Others 类别。
具有新维护版本（版本 r20260320.00_00 及更高版本）的 MySQL 实例具有 INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES 表，该表显示由长时间运行的查询创建且由 MySQL 取消关联（即文件存在，但未关联到 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 值。对于早期版本（
r20260117版或更早版本），您可以从SHOW FULL PROCESSLIST操作的输出中检索 PROCESS_ID 值。
终止导致临时文件磁盘消耗增加的查询后，这些更改最多可能需要大约 5 分钟才能在磁盘使用量指标中注册。
使用 Query Insights
我们建议使用 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：长时间运行的事务阻止撤消日志清除，可能会导致历史记录列表长度过长，这也可能会导致磁盘使用率问题。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 实例。