本页面介绍了已知的高磁盘用量问题，并提供了问题排查帮助。
已知的高磁盘用量问题包括：
- 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 进程）。
使用以下查询获取活跃的长时间运行的查询：
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或更高版本，您可以通过 SESSION_ID 列检索 PROCESS_ID 值。INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES对于早期版本（版本
r20260117或更低版本），您可以从 PROCESS_ID 值中检索SHOW FULL PROCESSLIST操作的输出。
终止通过临时文件导致磁盘消耗量增加的查询后，可能需要大约 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 实例。