前言：

MySQL 数据库服务器使用多种类型的日志来记录操作和事件，这对于故障诊断、审计和性能分析非常重要。然而，这些日志文件会随着时间的推移而不断增长，可能会占用大量的磁盘空间。因此，定期清理这些日志是必要的，本篇文章我们一起来学习下如何清理 MySQL 中的日志文件。

二进制日志 (Binary Log)

binlog 记录了数据库所有的 DDL（数据定义语言）和 DML（数据操作语言）更改操作，一般都是建议开启 binlog 的，要注意的是 binlog 会占用大量磁盘空间，特别是你的数据库特别繁忙的情况下。这个时候就要制定清理策略了。

MySQL 5.7 可以通过 expire_logs_days 参数来设置 binlog 删除时间，在 my.cnf 配置文件中设置 expire_logs_days 参数，指定二进制日志文件的过期天数，过期的日志文件将会自动被删除。在 MySQL 8.0 中建议使用 binlog_expire_logs_seconds 参数，此参数同样是控制二进制文件过期时间，单位是秒。binlog 具体要保留多久，可以根据磁盘空间决定，磁盘充足可以多保留，一般建议至少保留 7 天。

除了通过设置参数自动清理外，binlog 还可以使用 PURGE BINARY LOGS 命令来手动执行清理。例如，使用 purge binary logs to 'mysql-bin.000009' 来删除 mysql-bin.000009 之前的日志文件，或者使用 purge binary logs before '2024-07-15 00:00:00' 来删除指定时间之前的日志文件。

通用查询日志 (General Query Log)

MySQL 的 general_log 是记录所有到达 MySQL 服务器的 SQL 语句的日志。由于它记录了所有的 SQL 语句，包括连接、查询、更新等操作，因此其日志量可能增长非常迅速，通常在生产环境中不建议开启此功能，以免影响性能。如果你的数据库为了等保评测或者其他原因开启了 general_log ，那就要及时制定清理策略了。

官方并没有提供用于清理 general_log 的参数或命令，因此清理 general_log 只能各显神通了，一般情况下可以通过写 shell 脚本来执行清理，比如说每天凌晨进行日志切换，删除几天前的日志文件。也可以使用 logrotate 功能来配置 general_log 自动轮转及清理。

错误日志 (Error Log)

错误日志记录 MySQL 服务器启动、关闭及运行时发生的错误及警告信息。一般是默认开启的，不过错误日志增长速度很慢，通常不需要频繁清理，可以手动清理或设置定期任务清理旧的日志文件。错误日志保留时间可以更长些。

慢查询日志 (Slow Query Log)

慢日志主要用于记录执行时间超过设定阈值的 SQL 查询。慢查询日志对于数据库的性能优化非常重要，因为它可以帮助数据库管理员和开发者识别和优化那些执行效率低下的查询。慢日志也是建议开启的。

通常情况下，我们可以根据系统情况来设置慢 SQL 阈值，比如 1s 或 3s 。慢日志一般情况下增长速度也不是很快，只要持续进行 SQL 优化，慢日志会越来越少的。通常慢日志也不需要频繁清理，一般我们可以每一周或每一月重命名一次，然后保留几份这样来制定清理策略，可以交由 shell 脚本自动执行。

审计日志 (Audit Log)

MySQL 社区版官方并没有提供审计日志，如果想开启审计日志，只能借助 MariaDB 或 Percona Server 等其他审计插件。审计日志增长速度也比较快，一般审计插件都提供清理参数，比如说日志文件到达多少 M 自动轮换，保留几份日志文件等，一定要设置好此类参数，以防占用大量磁盘空间。

中继日志 (Relay Log)

中继日志是 MySQL 复制过程中用于存储从主服务器接收的二进制日志事件的临时日志文件。这些日志文件由从服务器用来应用来自主服务器的更新。中继日志只存在于从服务器上，relay log 文件会随着事件被应用而逐渐增长，因此也需要适当的清理策略来管理这些文件。

MySQL 官方提供了 relay_log_pure 参数，此参数决定了 relay log 文件在被完全应用后是否应该被自动删除。这个参数有两个可能的值：ON 和 OFF ，设置为 ON 代表当中继日志应用完成后会自动删除，OFF 则不会自动删除。一般情况下，建议开启此参数，这样 relay log 应用完就会被清理掉，不会占用大量磁盘空间。

如果你的从服务器要求关闭 relay_log_pure 参数，例如在 MHA 高可用架构下，为了确保在故障转移时能够使用 relay log 进行恢复，通常需要禁用从服务器上的中继日志自动清理功能。这个时候就要想其他办法来清理 relay log 了。MHA 提供了一个名为 purge_relay_logs 的 perl 脚本，可通过 purge_relay_logs 脚本配合 cronjob 来完成此清理任务。若 purge_relay_logs 脚本无法使用，那么只能自己写 shell 脚本了，比如可以定期将 relay_log_pure 设为 ON ，然后执行 flush relay logs 后，再将 relay_log_pure 设为 OFF ，这样操作下来一般也能实现清理 relay log 。实在不行我们还可以使用 find 命令来找到几天前的日志文件，然后直接 rm 清理掉，不过用 find 找到后直接 rm 删除这种方法会导致 relay-log.indx 索引文件中记录 relay log 与实际存在的不匹配，所以直接 rm 删除 relay log 后还要记得更新下 relay-log.indx 索引文件。

总结：

本篇文章简单介绍了 MySQL 中六种常见日志及其清理策略，不同环境可以采用不同的清理策略，本文只是提供一种思路，方法各种各样，重要的是要根据实际情况制定合理的日志保留策略，并确保不会影响到数据库的正常运行和备份需求。