我有一个包含三个大表的数据库，它具有以下特点：
- 三张表，每张表每小时大约有 15M 次插入。
- 没有更新。
Indexing在和的帮助下快速选择查询Partition。- 只保留数据 14 天，我使用PARTITION。每个分区一天。我在 23:50（新的一天开始之前）创建一个新
Partition的，然后删除 15 天前的分区。（快速准确） - 我每天备份数据集，一天。（仅昨天的数据）
我监视我的二进制日志 9 天，日志大小急剧增加。问题是：在某些时候，binlog 占用了我所有的磁盘空间。我的问题是：
- 就我而言，我需要 binlog 吗？（如果好处只是复制我现在不需要它）
- 管理 binlog 的最佳方式是什么？（如果我保留它）
Partition和binlog有什么关系吗？（如果我禁用它）
运行的命令、表和 MySQL 配置如下所示。
du -ch /var/lib/mysql/binlog.* | tail -n 1
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
| 日期 | 以 GB 为单位的总大小 |
|---|---|
| 2022-11-22 | 289GB |
| 2022-11-23 | 300GB |
| 2022-11-24 | 311GB |
| 2022-11-25 | 322GB |
| 2022-11-26 | 334GB |
| 2022-11-27 | 364GB |
| 2022-11-28 | 378GB |
| 2022-11-29 | 417GB |
| 2022-11-30 | 437GB |
二进制日志有几种用途：
如果这些用途中的一种或多种适用于您的情况，那么您应该保留二进制日志。你没有提供足够的信息让我知道这一点。
除非您使部分或全部文件过期，否则二进制日志会累积并变得越来越大。您可以使用PURGE BINARY LOGS手动执行此操作（这将不允许您删除最后一个二进制日志，因为当前正在写入该日志文件）。
在 MySQL 8.0 中，二进制日志也默认在 30 天后自动过期，或者您可以将其设置为不同的时间段（参见binlog_expire_logs_seconds）。
在 MySQL 5.x 中，您可以选择配置二进制日志的自动过期，但默认设置是永远保留所有二进制日志（请参阅expire_logs_days）。
请注意，过期意味着当二进制日志翻转以打开一个新文件时，它会检查最旧的文件，如果它们早于过期时间窗口，它们将被删除。请记住，在日志打开新文件之前不会发生这种情况。使用 MySQL 5.x 时，这可能会导致在进行大量数据导入/导出时文件不会过期的情况，因为文件期限的粒度以天为单位。换句话说，如果你的过期时间是超过1天的日志，但是你一天填满了500GB的数据，你可以累积500个binlog文件，而且没有一个超过1天的，所以它们还没有过期. 所以我很高兴他们在 MySQL 8.0 中将粒度更改为 1 秒。
分区和二进制日志之间没有特殊关系。二进制日志记录所有 DML 和 DDL 更改（尽管给定会话可能会禁止写入二进制日志）。
DDL 始终以语句格式写入二进制日志。根据表的大小，ALTER TABLE 不可能在二进制日志中占用更多空间。所以如果你的二进制日志增加很多，那是因为 DML (INSERT/UPDATE/DELETE)。您每天的 DROP PARTITION 概不负责。