MariaDB部分记录未更新：二进制日志与InnoDB数据不一致疑问

这种情况确实可能发生，主要分为以下几种场景：

1. 事务内部分语句未匹配目标记录 #

这是最常见的正常场景。当事务中的UPDATE语句没有匹配到任何行时（比如目标记录不存在、WHERE条件无匹配），语句会执行成功但不会修改数据。此时整个事务提交后，binlog会完整记录所有语句，但InnoDB中自然没有对应记录的更新。

例如你提供的事务：

BEGIN
UPDATE my_table SET status = 1, updated_at = NOW() WHERE id = 1
UPDATE my_table SET status = 1, updated_at = NOW() WHERE id = 2
UPDATE my_table SET status = 1, updated_at = NOW() WHERE id = 3
UPDATE my_table SET status = 1, updated_at = NOW() WHERE id = 4
UPDATE my_table SET status = 1, updated_at = NOW() WHERE id = 5
COMMIT

如果my_table中不存在id=2和id=3的记录，这两条UPDATE不会修改任何数据，但binlog仍会完整记录所有5条语句，最终InnoDB中只有id=1、4、5的记录被更新。

2. 事务提交阶段的异常中断 #

MySQL事务提交遵循以下逻辑：

1. 事务在InnoDB中完成所有语句执行；
2. 将整个事务内容写入二进制日志；
3. 通知InnoDB完成事务提交。

如果在步骤2完成后、步骤3执行前，数据库进程崩溃或服务器断电，重启后会出现：

• binlog中存在完整的事务记录；
• InnoDB因未收到提交确认，会回滚整个事务，所有更新都不会生效。
  这种场景下是整个事务未生效，而非部分语句。

3. 极端bug导致的日志与引擎状态不一致 #

正常情况下，若事务最终被回滚（无论是应用显式执行ROLLBACK，还是因严重错误触发自动回滚），MySQL不会将该事务写入binlog。但在极少数特定版本的MySQL bug场景中，可能出现binlog记录了事务，但InnoDB实际回滚的情况。这类问题通常会在后续版本中被修复。

4. 人为操作导致日志与实际执行脱节 #

比如通过mysqlbinlog导出事务语句后，手动将其写入binlog但未在数据库中实际执行；或使用第三方工具修改binlog内容。这种属于非正常操作场景，不属于数据库运行的常规情况。

内容的提问来源于stack exchange，提问作者mike watawski