mariadb 在短时间内生成了一个巨大的带有不可读条目的 binlog
mariadb generates a huge binlog with unreadable entries in a short time
MariaDB 10.4.6 (Windows)
binlog_format = 行
我的二进制日志爆炸了。几天以来我有很多这样的条目：
#201005 9:35:11 server id 14020 end_log_pos 262175992 CRC32 0xce45fdf1 Update_rows: table id 433 flags: STMT_END_F
BINLOG '
r8x6XxPENgAAewAAACY/nw8AALEBAAAAAAEAE215c3FsbW9uaXRvcl9lbmdpbmUAGm1pc19teXNx
bF9pbnN0YW5jZXNfc3RhdHVzABYBDxL+AgICDw8DCQkBCQ8BAg8ICA8SEDIAAP4DCgAeAPoAFABQ
wwAAoBOICLzi ...
确实有很多行。我每秒多次发现如此大的条目。现在每 6 分钟就会创建一个新的 250MB 二进制日志文件（之前是每隔几个小时）。
我最近将 binlog_format 从默认值 (MIXED) 更改为 ROW。就是这样。
该行为的原因是什么，这些条目的目的是什么？我该怎么做才能抑制这些不可读的条目？
最可能的原因是修改大量行的语句相对较少。启用通用日志（或 long_query_time=0 的慢速日志），您将捕获服务器执行的所有语句。这应该可以帮助您找到以这种方式运行的查询。
基于语句的binlog存储修改数据的语句。在某些边缘情况下，这不是确定性的。基于行的 binlog 存储所有被修改的行。如果你有一条语句修改了大 table 中的每一行，整个 table 将在二进制日志中结束 twice （原始行和新行是存储在基于行的二进制日志中 - 用于匹配目的的完整旧行，以及完整的替换行）。
您无法更改此行为，这是基于行的二进制日志工作方式的本质。要减少 space 要求，您唯一可以做的就是将二进制日志放在压缩文件系统上或减少它们的保留期。
MariaDB 10.4.6 (Windows)
binlog_format = 行
我的二进制日志爆炸了。几天以来我有很多这样的条目：
#201005 9:35:11 server id 14020 end_log_pos 262175992 CRC32 0xce45fdf1 Update_rows: table id 433 flags: STMT_END_F
BINLOG '
r8x6XxPENgAAewAAACY/nw8AALEBAAAAAAEAE215c3FsbW9uaXRvcl9lbmdpbmUAGm1pc19teXNx
bF9pbnN0YW5jZXNfc3RhdHVzABYBDxL+AgICDw8DCQkBCQ8BAg8ICA8SEDIAAP4DCgAeAPoAFABQ
wwAAoBOICLzi ...
确实有很多行。我每秒多次发现如此大的条目。现在每 6 分钟就会创建一个新的 250MB 二进制日志文件（之前是每隔几个小时）。 我最近将 binlog_format 从默认值 (MIXED) 更改为 ROW。就是这样。
该行为的原因是什么，这些条目的目的是什么？我该怎么做才能抑制这些不可读的条目？
最可能的原因是修改大量行的语句相对较少。启用通用日志（或 long_query_time=0 的慢速日志），您将捕获服务器执行的所有语句。这应该可以帮助您找到以这种方式运行的查询。
基于语句的binlog存储修改数据的语句。在某些边缘情况下，这不是确定性的。基于行的 binlog 存储所有被修改的行。如果你有一条语句修改了大 table 中的每一行，整个 table 将在二进制日志中结束 twice （原始行和新行是存储在基于行的二进制日志中 - 用于匹配目的的完整旧行，以及完整的替换行）。
您无法更改此行为，这是基于行的二进制日志工作方式的本质。要减少 space 要求，您唯一可以做的就是将二进制日志放在压缩文件系统上或减少它们的保留期。