当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 临时表打满磁盘复盘：报表接口从超时到恢复

MySQL 临时表打满磁盘复盘：报表接口从超时到恢复

来源：17golang原创 2026-06-29 17:15:30 0浏览收藏

线上报表接口突然超时，应用日志只看到请求超过 30 秒，MySQL 慢日志里出现大量 Using temporary 和 Using filesort。几分钟后，数据库所在磁盘空间告警，部分查询开始报错。这个场景很容易被误判成“普通慢 SQL”，但真正的问题可能是临时表落盘后持续放大，最终把磁盘打满。

本文按一次故障复盘的方式拆解：影响面是什么，时间线怎么推进，哪个条件触发了临时表落盘，根因如何确认，临时怎么止血，后续怎么避免同类问题再次发生。

影响面：报表接口超时并伴随磁盘告警
时间线：从慢请求到磁盘空间耗尽
触发条件：大范围 GROUP BY 让临时表落盘
根因定位：不是单次慢，而是临时表持续堆积
修复动作：先止血，再改查询路径
防复发：监控临时表、限制范围和预聚合

影响面：报表接口超时并伴随磁盘告警

故障最先从业务侧暴露出来：运营后台打开“订单渠道日报”时，页面一直转圈，最后提示请求超时。接口层看到的是 /api/report/channel-daily 多次超过 30 秒。

数据库侧同时出现两个信号：

慢日志里同一条聚合 SQL 反复出现，扫描行数超过百万。
磁盘剩余空间快速下降，随后触发空间告警。

这说明问题不是单个请求偶发慢，而是某类查询在高频访问下持续消耗数据库资源。此时处理目标有两个：先保护数据库磁盘空间，再定位报表 SQL 为什么制造大量临时数据。

MySQL 临时表打满磁盘故障修复前后对照：报表超时、磁盘告警到限制范围和预聚合恢复

时间线：从慢请求到磁盘空间耗尽

按时间线梳理，故障过程大致是这样：

10:02：新报表入口上线，默认查询最近 90 天数据。
10:06：运营同事开始集中访问，接口 P95 延迟升到 18 秒。
10:09：慢日志出现多条 Using temporary; Using filesort。
10:12：磁盘空间告警，临时目录所在分区剩余不足 10%。
10:15：临时关闭报表入口，数据库压力开始回落。

这个时间线很关键。它说明数据库不是一开始就不可用，而是在新报表入口上线后，被大量宽范围聚合查询逐步压垮。排查时不能只盯一条最慢 SQL，还要看它被调用的频率和临时数据增长速度。

触发条件：大范围 GROUP BY 让临时表落盘

触发 SQL 简化后类似下面这样：

SELECT
  channel,
  DATE(created_at) AS day,
  COUNT(*) AS order_count,
  SUM(pay_amount) AS pay_amount
FROM orders
WHERE created_at >= '2026-03-01'
  AND created_at

这条 SQL 有几个危险点：

默认时间范围太大，一次扫描三个月订单。
DATE(created_at) 让分组表达式和索引顺序不完全匹配。
GROUP BY 加 ORDER BY 需要额外排序。
并发访问时，每个查询都可能生成自己的临时表。

当内存临时表放不下时，MySQL 会把临时表写到磁盘。单次查询慢还不是最坏情况，真正危险的是多个大查询同时执行，磁盘临时文件持续增长。

根因定位：不是单次慢，而是临时表持续堆积

定位时可以先看几个状态指标：

SHOW GLOBAL STATUS LIKE 'Created_tmp%';
SHOW GLOBAL STATUS LIKE 'Sort_merge_passes';
SHOW VARIABLES LIKE 'tmpdir';

如果 Created_tmp_disk_tables 在故障期间快速增长，并且 tmpdir 所在磁盘空间同步下降，就可以把排查方向从“普通慢查询”推进到“磁盘临时表放大”。

MySQL 临时表故障根因对照：Created_tmp_disk_tables 增长、tmpdir 空间下降和修复后指标恢复

再结合 EXPLAIN 查看执行计划：

EXPLAIN
SELECT channel, DATE(created_at) AS day, COUNT(*), SUM(pay_amount)
FROM orders
WHERE created_at >= '2026-03-01'
  AND created_at

如果 Extra 里出现 Using temporary 和 Using filesort，并且扫描行数很大，就能解释为什么报表访问一多就把临时目录打满。

修复动作：先止血，再改查询路径

这类故障不要一开始就重构报表。先止血，恢复数据库空间和业务可用性。

第一步：限制入口

临时关闭报表入口，或把默认时间范围从 90 天缩到 7 天，阻止新的大范围聚合继续进入数据库。

第二步：清理和扩容临时空间

确认没有长期运行的大查询后，再处理临时目录空间。必要时把 tmpdir 放到空间更充足的分区，但这只是缓解，不是根治。

第三步：改查询模型

日报表更适合预聚合。可以每天或每小时把渠道维度写入汇总表：

CREATE TABLE order_channel_daily (
  stat_day DATE NOT NULL,
  channel VARCHAR(32) NOT NULL,
  order_count BIGINT NOT NULL,
  pay_amount DECIMAL(12,2) NOT NULL,
  PRIMARY KEY (stat_day, channel)
);

查询报表时直接读汇总表，避免每次都从订单明细表现场聚合。

防复发：监控临时表、限制范围和预聚合

故障恢复后，要把防线补齐。

监控 Created_tmp_disk_tables 增速，而不是只看慢日志。
监控 tmpdir 所在分区空间，设置更早的告警阈值。
报表入口限制最大时间范围，默认不要给 90 天或全量。
高频报表走汇总表或缓存，明细表只用于追查。
上线前用接近生产的数据量验证 EXPLAIN 和接口耗时。

复盘的结论不是“以后不要用 GROUP BY”，而是大范围、高并发、实时聚合不能直接压到明细表上。报表系统要把查询范围、预聚合、临时表监控和降级入口一起设计。

总结

MySQL 临时表打满磁盘通常不是一个孤立 SQL 的问题，而是查询范围、排序分组、并发访问和临时目录空间共同作用的结果。排查时按时间线看影响面，结合 Created_tmp_disk_tables、tmpdir 空间和 EXPLAIN 定位根因；修复时先限制入口止血，再改成汇总表或更小范围查询；最后把临时表和磁盘空间纳入监控，才能真正防复发。