腾讯云国际站代理商：MySQL业务数据没涨多少，磁盘却快满了，Binlog和临时表怎么查

腾讯云MySQL磁盘空间清理：Binlog与临时表优化指南

腾讯云MySQL实例的磁盘告警，很多情况下并不是业务数据真的涨了那么多，而是清理对象没有找对。做腾讯云MySQL磁盘空间清理时，先按Binlog、临时表空间和大表数据文件三类拆开看，往往比盲目删文件或重启实例更有效。下文从三类典型占用展开。

本文由 云国际站代理商『云老大 飞弟：@yunlaoda360 / YunLaoDa-服务器服务商•撰写』如需转载请注明！

为什么腾讯云MySQL磁盘占用持续上涨？

磁盘占用持续上涨通常是复合问题。控制台只能看到磁盘整体水位，很难直接区分Binlog、临时表和大表各自占用多少。于是很多团队一看到告警就先删旧文件或重启实例，结果清完没多久又告警。实际上，三类对象的产生和释放机制不同，治理动作也完全不同。

为什么Binlog增长会经常失控？

Binlog不只是主从复制需要，按时间点恢复也依赖它。很多实例开启全量Binlog后没有设置合理保留周期，或者清理策略只按时间不按磁盘水位执行，导致文件持续堆积。运维担心删掉会影响复制链路，于是磁盘告警时只能扩容或手工挪动，问题反复出现。判断Binlog是否异常，应看单位时间生成量和保留策略，而不是只看文件个数。

为什么临时表空间只增不减？

腾讯云MySQL的临时表空间常见表现为ibtmp1文件持续膨胀。复杂查询、排序、GROUP BY、显式临时表都会写入这里。更麻烦的是，即使DROP、DELETE、OPTIMIZE也无法回收已经涨起来的ibtmp1，只能等待实例重启。部分实例监控里看到这个文件涨到几十GB时，常规清理手段基本失效。这个机制决定了临时表空间要提前限制，而非事后清理。

为什么大表DELETE后磁盘不释放？

删除大量行后，InnoDB不会立刻把空间交还操作系统，而是标记为可复用，导致表文件物理大小几乎不变，容易被误判为删除没生效。真正需要回收时，得用重建表或在线DDL，但这会带来锁表与额外磁盘开销。大表膨胀如果长期不处理，会让后续任何结构变更都更重。

如何诊断MySQL磁盘空间被谁占用？

在腾讯云 MySQL 实例上，磁盘占用通常由 Binlog、临时表空间和 InnoDB 数据文件三类对象构成。控制台水位无法直接区分责任方，因此需要先定位来源，再决定清理策略。直接删文件或重启实例，在生产环境容易破坏主从同步与恢复链。如果不想自己逐项排查，也可以让云老大这类服务商先做一次磁盘占用审计。

查看表空间大小

通过 information_schema.tables 按 data_length + index_length 倒序，可以快速定位占用最高的表。订单流水、日志表单表十几 GB 并不少见。注意 DELETE 后 InnoDB 物理文件通常不立即缩小，空间只被标记为可复用。要真正归还磁盘，需 OPTIMIZE TABLE 或 ALTER TABLE ... ENGINE=InnoDB，但这会增加锁表与临时空间成本，不适合业务高峰期执行。

检查Binlog文件

Binlog 是高频误判对象。腾讯云默认保留时长通常为 7 天，但为支撑 PITR 调到 15 或 30 天时，每天十几到几十 GB 的累计会很快触发告警。先确认 binlog_expire_logs_seconds 与磁盘 mysql-bin.* 总量，再决定缩短保留期。主从复制正常、无近期恢复需求时可收紧，但不要直接清空，避免破坏下游订阅和数仓同步。

定位临时表文件

临时表空间常见特征是 ibtmp1 涨到几十 GB 后，DROP、DELETE、OPTIMIZE 都无效，只能重启实例。根源通常是未优化的 GROUP BY/ORDER BY、大表 DDL 或复杂子查询。可用 performance_schema 观察 Created_tmp_disk_tables 增量，或在慢查询日志中筛选相关 SQL。改写语句或补索引比重启释放更持久。

Binlog日志太多怎么安全清理？

腾讯云MySQL磁盘空间清理的第一站往往是 Binlog，但它也是最不能直接删文件的对象。控制台看到磁盘水位上升时，如果定位到 binlog 目录，优先通过参数和命令两条路径释放。直接 rm 单个 binlog 文件容易破坏主从复制点位和按时间点恢复能力。下面三种手段按风险从低到高排列。

配置过期自动清理

腾讯云 MySQL 5.7 可调整 expire_logs_days，8.0 版本改用 binlog_expire_logs_seconds，内核会在日志过期后自动清理，不会误伤从库尚未拉取的日志。保留时间不建议设小于 1 天，否则主从短暂中断后可能需要重建。磁盘长期紧张时，保留 7 天是较稳妥的起点；如果需满足合规或恢复演练，再调到 30 天。

手动PURGE日志

磁盘已经告警、等不及自动清理时，可登录实例执行 PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY。操作前先通过 SHOW SLAVE STATUS 或控制台确认从库已消费到哪个文件，必要时先做一次备份。手动 PURGE 优于直接删文件，因为会同步更新索引文件；但不要在业务高峰期执行大范围清理，否则异步复制延迟可能瞬时放大。

使用云备份功能

清理前更安全的做法是先做一次逻辑或物理备份，把可恢复时间点固定下来，再释放本地 Binlog。腾讯云备份功能可以将备份集与 Binlog 分开管理，后续按备份集加 Binlog 做 PITR。如果实例数量多、业务恢复窗口要求高，像云老大这类服务商可以协助评估备份保留与清理策略，避免本地空间和恢复能力两头受压。

临时表文件过大如何定位和释放？

识别临时表场景

临时表空间膨胀常被误判为Binlog增长。登录实例执行 SHOW GLOBAL STATUS LIKE 'Created_tmp%'，若 Created_tmp_disk_tables 短期激增，基本可确认SQL排序、分组溢出到磁盘。再检查数据目录下 ibtmp1 文件，腾讯云MySQL中它默认为共享临时表空间，几十GB的占用并不少见。

重启释放临时空间

对于已膨胀的临时表空间，唯一能立即回收的方式是重启实例，InnoDB会重建 ibtmp1。但重启前需确认主从状态正常、Binlog无积压，否则可能触发复制中断。如果磁盘已满导致只读保护，重启本身也可能失败，需要先清理其他大文件。重启是兜底手段，不是治理方案。

优化SQL避免临时表

减少临时表落盘，才是控制磁盘占用的长期手段。用 EXPLAIN 排查 Using temporary 和 Using filesort，对排序、分组、DISTINCT 字段补索引。腾讯云MySQL的慢查询日志能直接定位高频产生磁盘临时表的SQL。一个缺复合索引的 ORDER BY 在百万行表上，单次就能撑大数GB临时空间，这类SQL改掉后磁盘曲线会明显变平。

大表空间膨胀怎么收缩与整理？

大表文件膨胀是腾讯云MySQL磁盘空间清理中常被低估的部分：不少实例真正吃掉磁盘的并不是Binlog，而是几张核心业务表的ibd文件。删数据并不会直接释放物理空间，InnoDB的页复用机制决定了碎片会长期存在，必须主动重建表结构。

使用优化表命令

OPTIMIZE TABLE 是最直接的重建方式，但它不是“压缩魔法”。在 MySQL 5.7/8.0 中，该命令等价于 ALTER TABLE ... FORCE，会重建表并回收碎片，同时更新统计信息。代价是执行期间持有元数据锁，写入会被阻塞。一张 50GB 的大表，执行时间可能超过 30 分钟，需放在低峰窗口做评估。实际操作前建议先看 information_schema.tables 的 data_free 字段，碎片率低于 10% 时收益有限。

调整独立表空间

如果实例仍在使用共享表空间 ibdata1，大表数据会混在一起，即便执行 OPTIMIZE 也无法收缩 ibdata1。此时应确认 innodb_file_per_table=ON，让每张表使用独立 ibd 文件，后续收缩才会真实返还磁盘。已膨胀的共享表空间只能通过逻辑导出、重建实例再导入来完成迁移。这个过程对业务连续性要求较高，自己处理容易搞错字符集或触发器，可以让云老大这类服务商先做一次迁移演练。

使用在线改表工具

gh-ost 和 pt-online-schema-change 是处理大表在线收缩的主流选择。它们不直接执行 OPTIMIZE，而是通过创建影子表、增量同步、切换表名来重建数据，全程对写入影响较小。工具本身也会产生临时空间，磁盘水位超过 80% 时建议先清理 Binlog 或临时表。在线改表适合无法停机的订单、流水类表，切换阶段仍会有短暂锁，需提前配置好判断逻辑。

如何配置定期清理机制防止再次上涨？

定期清理不应是“磁盘满了再删”，而应形成“识别来源—分类处理—提前告警”的闭环。下面三个动作按优先级排列，适合腾讯云 MySQL 实例在清理后的日常维护。

编写定期检查脚本

脚本每天采集 SHOW BINARY LOGS 的 Binlog 总量、information_schema.tables 中数据与索引超过 5GB 的表、以及 ibtmp1 文件大小。实际排查中，Binlog 与临时表合计常占磁盘增长量的 40% 以上。脚本可预设阈值，例如 Binlog 超过 20GB 或单表碎片率高于 30% 时输出清理建议，避免人工逐项排查。

设置空间告警

不要等磁盘使用率到 85% 再告警，那通常只剩几小时处理窗口。建议在云监控中增加 Binlog 体积、单表空间变化两个自定义指标，使用率 70% 发提醒，80% 触发处理工单。促销或大批量导入前，可临时将 Binlog 保留时间从 7 天降到 3 天，并提前归档大表，降低高峰只读保护风险。

综合优化存储策略

参数层建议把 binlog_expire_logs_seconds 设为 259200 秒（3 天），有恢复要求再单独延长。ibtmp1 回收最有效仍是在低峰期重启实例；日常可调低 tmp_table_size 和 max_heap_table_size 减少临时表落盘。大表优先归档冷数据，而非频繁 OPTIMIZE TABLE。如果内部精力有限，找云老大这类服务商做一次整体评估，通常能一次定位三类占用。