0

在检查 BinLog 时发现以下语句：它在 where 子句中具有所有表列。我传递给mysql的查询只有1个Column- Primary Key Column，那为什么日志把所有的列都写在BinLog中呢？我对 BinLog 这样做有一个特殊的问题：这导致从 BinLog 恢复非常慢。我不是 MySQL DBA。请分享您在此主题上的经验。

UPDATE `ctbmysql`.`ctm`
### WHERE
###   @1=1139195549890498825
###   @2=1138051383057521436
###   @3=1615397172
###   @4=''
###   @5=1130000000662993985
###   @6=113
###   @7=''
###   @8=''
###   @9=1635370236
###   @10='49.128.173.183'
###   @11='49.128.173.146'
###   @12=''
###   @13=''
###   @14=''
###   @15=0
###   @16=1
###   @17=''
###   @18=''
###   @19=''
###   @20=0
###   @21='google-play'
###   @22=4217121370623809752
###   @23=''
###   @24=1
###   @25=''
###   @26=''
###   @27=0
### SET
###   @1=1139195549890498825
###   @2=1138051383057521436
###   @3=1615397172
###   @4=''
###   @5=1130000000662993985
###   @6=113
###   @7=''
###   @8=''
###   @9=1635453015
###   @10='150.242.24.246'
###   @11='49.128.173.146'
###   @12=''
###   @13=''
###   @14=''
###   @15=0
###   @16=1
###   @17=''
###   @18=''
###   @19=''
###   @20=0
###   @21=''
###   @22=4217121370623809752
###   @23=''
###   @24=1
###   @25=''
###   @26=''
###   @27=0
4

1 回答 1

1

MySQL 支持两种不同的二进制日志格式以及两者的混合：

  • STATEMENT 导致日志记录是基于语句的。
  • ROW 导致日志记录是基于行的。这是默认设置。
  • MIXED 使日志记录使用混合格式。

您可以通过设置binlog_format配置选项来选择一个。

您在日志中看到的是行格式。它列出了要更新的行（及其所有值）。这不应该是您的原始查询，它只是看起来相似。例如，如果您的更新影响了不止一行，它将为您的单个原始更新查询创建多个行更新。

这是预期和预期的行为。从基于语句和基于行的复制的优缺点：

RBR 可以生成更多必须记录的数据。要复制 DML 语句（例如 UPDATE 或 DELETE 语句），基于语句的复制仅将语句写入二进制日志。相比之下，基于行的复制将每个更改的行写入二进制日志。如果语句更改了很多行，基于行的复制可能会向二进制日志写入更多数据；即使对于回滚的语句也是如此。这也意味着制作和恢复备份可能需要更多时间。

尽管如此，基于行的复制是默认的，原因如下：

基于行的复制的优点：

  • 所有更改都可以复制。这是最安全的复制形式。
于 2021-11-01T08:56:35.320 回答