蜻蜓Q系统旗舰版明星案例产品私鱼创作系统——关于数据量激增后数据库API日志及大文件记录占用的详细清 - 文章 - 开发者社区

蜻蜓Q系统旗舰版明星案例产品私鱼创作系统——关于数据量激增后数据库API日志及大文件记录占用的详细清理处理方法（通用指南）

一、背景概述

私鱼创作系统作为优雅草科技旗下蜻蜓Q系统的旗舰级明星案例产品，目前已稳定商业化运营超过两年，积累了大量真实用户与高频业务数据。该产品的核心技术方案由优雅草科技提供，客户主体为沈阳岩羊科技有限公司，是优雅草科技长期合作的经典老客户之一。

截至目前，私鱼创作系统累计充值流水已突破百万级规模，业务增长态势良好，客户方正在基于现有成熟架构，积极规划打磨下一代全新版本产品，以进一步提升用户体验与平台价值。

系统上线以来，每日API请求量稳定维持在 5万至10万次 之间，业务并发压力较大，数据积累速度极快，如上图中监控数据所示。

截至目前，系统累计充值记录已超过 4万条，业务流水健康，用户活跃度持续走高，如下图所示。

然而，随着业务量持续增长，系统运行过程中也逐渐暴露出一些运维层面的挑战。最典型的问题集中在 存储资源消耗过快 方面：

服务器硬盘在短时间内因大量请求日志、数据库操作日志及框架运行时日志的持续写入，频繁出现存储空间占用过高的情况；
长期运行状态下，日志文件及数据表占用空间通常达到 50GB至70GB 左右，每次执行系统性的清理操作后，存储状态可恢复正常，如下图所示。

特别值得关注的是，API请求日志增长尤为迅猛。以最近3天的数据为例，API请求记录已达 23万条，初步估算占用存储空间约 10GB，具体数据如下图所示。

由此可见，建立一套规范化、标准化且安全的日志与缓存数据清理机制，已成为保障系统长期稳定运行的关键运维工作。

二、总体处理方案

针对上述存储资源占用问题，结合私鱼创作系统的实际技术架构（基于Laravel框架 + MySQL数据库），我们制定并验证了以下三类核心清理措施，涵盖数据库层面、操作系统层面及应用框架层面，具体方案如下。

1. 清理 API 请求日志表（api_log）

数据库中的 api_log 表用于记录每一次API接口的请求详情，包括请求路径、参数、响应状态、耗时、IP地址及时间戳等信息。由于每笔业务请求均会写入该表，其数据量增长极为迅速，是该系统中最主要的存储占用来源之一。

操作步骤

登录MySQL数据库管理工具（如phpMyAdmin或通过命令行客户端），连接到对应数据库实例。
定位到 siyu 数据库，找到 api_log 数据表。
执行清空操作时，务必使用 TRUNCATE 方式，而非 DELETE 语句。

- TRUNCATE 操作会直接重置表结构并释放物理存储空间，效率远高于逐行删除的 DELETE 操作；
- 该操作会重置自增主键计数，且无法回滚，请务必在执行前确认当前环境为可清理状态。

执行 TRUNCATE 时，系统会弹出确认提示，例如：

“您将要完全清空一个表！您真的要执行 TRUNCATE TABLE siyu.api_log 吗？”

请确认后点击执行，注意该对话框默认会勾选“外键约束检查”，通常无需修改，直接确认即可。

注意事项

TRUNCATE 操作不可恢复，执行前建议先进行数据备份或导出近期关键日志（如需保留分析数据）；
若业务上有日志审计需求，可考虑将历史日志定期归档至独立的历史表中，再进行清理；
该操作不会影响业务正常运行，但建议在业务低峰期执行。

2. 清理 MySQL 二进制日志（Binary Log）

MySQL 的二进制日志（Binary Log）是数据库中另一类占用空间较大的文件。这些文件记录了数据库执行的所有结构性变更操作（如 INSERT、UPDATE、DELETE、DDL 等），是数据复制与恢复的重要基础。

2.1 这些文件是什么？

文件全称：MySQL Binary Log（二进制日志）

通俗理解：

它就像一本 操作日记本，按顺序记录了数据库每一次数据修改的详细过程；
文件命名格式如 mysql-bin.000191、mysql-bin.000192 等，每个文件相当于日记本中的一页；
当单个文件写满（默认上限为 1GB）时，系统会自动切换到下一个编号文件继续记录。

2.2 为什么占用空间这么大？

在私鱼创作系统中，典型情况如下：

每个二进制日志文件默认最大为 1GB；
当前目录下可能同时存在数十个文件，例如本例中存在编号从 191 到 203 的共计 13个文件；
总计占用空间约为 13GB 甚至更多。

产生的根本原因在于：

系统业务请求频繁，每次 API 调用往往伴随数据库写入操作，均会被记录到 binlog 中；
api_log 表每日写入量巨大，直接驱动了 binlog 的快速滚动与增长；
若未配置自动清理策略，这些文件将持续累积，最终导致磁盘空间耗尽。

2.3 这些日志的主要用途

用途	说明	当前系统是否需要
主从复制	主库将 binlog 发送给从库，从库重放以实现数据同步	如未部署主从架构，则不需要
数据恢复	利用 binlog 将数据库恢复到特定时间点	如有定期全量备份，则不需要长期保留
增量备份	在全量备份基础上，通过 binlog 实现增量恢复	如已有完善备份策略，则无需保留过多历史文件

2.4 为什么要定期清理？

长期累积 → 磁盘占满 → 数据库无法写入 → 服务不可用 → 业务中断

因此，定期清理旧的 binlog 文件，是保障数据库健康运行的基本运维操作。

2.5 清理操作详解

第一步：查看当前有哪些二进制日志文件

SHOW BINARY LOGS;

该命令会列出当前所有 binlog 文件列表及大小，便于确认当前状态。

第二步：安全删除指定文件之前的日志

重要原则：不能直接删除中间的文件！MySQL 的 binlog 是按顺序链式依赖的，如果删除中间某个文件，会导致：

MySQL 服务报错；
主从复制中断（若存在）；
数据恢复不连续、不完整。

正确做法：使用 PURGE BINARY LOGS TO 命令，删除指定文件之前的全部文件。

示例：

PURGE BINARY LOGS TO 'mysql-bin.000200';

该命令表示：删除 mysql-bin.000200 之前的所有日志文件，保留该文件及之后的文件。

第三步：确认删除结果

SHOW BINARY LOGS;

再次查看，确认旧文件已被清理，空间释放。

第四步：设置自动清理策略（推荐）

通过设置全局变量 expire_logs_days，可让 MySQL 自动清理 N 天前的 binlog：

-- 设置保留最近 7 天日志
SET GLOBAL expire_logs_days = 7;

-- 验证是否生效
SHOW VARIABLES LIKE 'expire_logs_days';

但由于部分云服务器或托管环境对 SUPER 权限有限制，该命令可能执行失败。此时可采用更保守且稳妥的方式：

-- 删除 2 天前的所有 binlog
PURGE BINARY LOGS BEFORE NOW() - INTERVAL 2 DAY;

或者再次尝试设置保留天数：

-- 查看当前保留天数设置
SHOW VARIABLES LIKE 'expire_logs_days';

-- 设置为保留 2 天
SET GLOBAL expire_logs_days = 2;

如果遇到如下权限错误提示：

#1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation

说明当前数据库账户不具备 SUPER 权限。此时应使用 root 账户 或具备相应管理权限的账户重新登录执行即可。

3. 清理 Laravel 框架运行时日志与缓存文件

除数据库层面外，Laravel 应用框架自身也会生成大量运行时日志和缓存文件，长期运行后同样会占用可观的磁盘空间。私鱼创作系统的后端服务基于 Laravel 框架构建，相关日志目录主要集中在 storage 路径下。

操作路径

/www/wwwroot/siyu-api/storage/logs

操作步骤

通过服务器终端或文件管理工具进入上述目录；
该目录下主要存放框架运行时输出的各类日志文件，例如：

- laravel.log（框架主日志，通常保留最新即可）
- query.log（SQL 查询日志，可安全删除）
- 其他自定义日志文件（根据实际命名判断）

重要注意事项

只能删除 logs 目录下的日志文件，切勿删除该目录本身，否则会导致 Laravel 运行时写入日志失败，进而引发服务异常；
laravel.log 文件不要删除，建议保留最新内容或仅清空内容（可考虑用 > laravel.log 命令清空）；
其他如 query.log、error.log 等历史日志文件，均可安全删除；
删除操作务必通过终端或文件管理器中的“删除”功能执行，确保文件被移入回收站后，还需要在回收站中彻底清除，才能真正释放磁盘空间。

补充建议

可考虑在 config/logging.php 中调整日志切割策略，例如按日切割或限制日志最大保留天数，从源头控制日志文件膨胀；
可使用 logrotate 工具实现系统级的日志轮转与自动清理，减少人工干预。

三、清理效果总结

按照以上三个步骤依次执行清理操作后，我们成功释放了大量被无用日志占用的存储空间。

在最新一次运维操作中，通过清理 api_log 表、删除过期 MySQL binlog 以及清除 Laravel 框架历史日志文件，累计释放空间约 70GB，磁盘使用率恢复至健康水平，系统运行状态显著改善。

四、运维建议与长效机制

为了降低后续人工清理频率，提升系统稳定性，建议结合实际情况建立以下长效机制：

设置 MySQL binlog 自动过期策略
如环境支持，优先通过 expire_logs_days 或 binlog_expire_logs_seconds（MySQL 8.0+）设置自动清理，推荐保留 2~7 天。
定期归档 API 日志
对 api_log 表可设计分区表策略，按月或按周分区，定期剥离旧分区并归档至冷存储。
应用层日志轮转
利用 Laravel 的日志通道配置或 logrotate 工具，实现按日切割与自动压缩。
建立监控告警
对磁盘使用率设置阈值告警（如超过 80% 即通知运维），实现主动响应。
制定标准操作文档
将上述清理流程文档化、脚本化，确保每次操作规范、可审计，降低误操作风险。

通过以上系统性的治理措施，私鱼创作系统在保持高并发业务处理能力的同时，亦可有效控制存储成本，为后续产品迭代与用户增长提供稳定可靠的基础支撑。