事务在binlog中以Xid_log_event为结束标志、与其前连续event共同构成逻辑单元；BEGIN不标志开始，首个变更event才起始，Xid唯一标识事务提交且保证原子性。
事务在binlog里到底以什么为单位划分
MySQL 8.0 中，一个事务在 binlog 文件里不是靠 BEGIN 或 COMMIT 语句本身来划界的，而是靠一组连续的、带事务上下文的 event 组合。最核心的判断依据是：Xid_log_event（提交事件）和它前面紧邻的 Query_log_event（BEGIN）、Table_map_log_event、Write_rows_log_event 等是否属于同一事务 ID 且位置连续。
关键点在于：binlog 不记录空事务，也不记录纯 BEGIN；BEGIN 只会触发一个 Query_log_event（内容为 BEGIN 字符串），而真正标志事务开始的是后续第一个变更操作对应的 event；事务结束由 Xid_log_event 唯一标识。
-
Xid_log_event是事务提交的“锚点”，它的Xid=xxx值与前面所有属于该事务的 event 共享同一个内部事务 ID - 同一个事务产生的所有 binlog event 在文件中一定是物理连续的，中间不会插入其他事务的 event
- 如果用了
autocommit=1，每条 INSERT/UPDATE/DELETE 都会自带隐式BEGIN和COMMIT，对应独立的Xid_log_event -
ROLLBACK不产生任何 binlog event —— 这是 binlog 只记录已提交变更的根本体现
用 mysqlbinlog 解析时怎么一眼识别事务边界
执行 mysqlbinlog --base64-output=decode-rows -vv 后，事务边界有非常明确的视觉特征：
- 每个事务开头通常是一个
# at xxx行 +Query_log_event，内容为BEGIN（显式事务）或空（autocommit 单语句） - 中间是若干
Table_map_log_event+Write_rows_log_event/Delete_rows_log_event/Update_rows_log_event，每条都带table id和字段值镜像 - 结尾一定是
# at yyy行 +Xid_log_event，末尾带COMMIT/*!*/; - 注意：
COMMIT文本只是注释，真正起作用的是Xid_log_event结构体本身
示例片段（简化）：
...# at 1233 # Query thread_id=8 BEGIN # at 1308 # Table_map: `test`.`t_binlog` mapped to number 95 # at 1369 # Write_rows: table id 95 flags: STMT_END_F ### INSERT INTO `test`.`t_binlog` ### SET ### @1=1 ### @2=100 ### @3='MySQL 核心模块揭秘' # at 1438 # Xid = 32 COMMIT/*!*/;
为什么不能只靠 position 或时间戳定位事务
单纯用 --start-position 或 --start-datetime 定位，极大概率切在事务中间，导致恢复失败或数据不一致。原因如下：
- 一个事务可能跨多个 binlog 文件（尤其大事务 +
max_binlog_size触发轮转） - 同一秒内可能有多个事务提交，
--start-datetime无法区分先后顺序 - position 是字节偏移量，不是逻辑事务单位；从中间 position 开始解析，可能漏掉
Table_map_log_event，导致后续Write_rows_log_event无法识别表结构 - GTID 模式下更明显：必须用
SET GLOBAL gtid_purged='xxx'+CHANGE MASTER TO ... GTID_SET=...才能精准跳过已执行事务
真正安全的做法是：先用 SHOW BINLOG EVENTS IN 'mysql-bin.000395' FROM 1233 LIMIT 20 查看 event 类型和位置，找到完整的 Xid_log_event 结束点，再以该 position 作为下一个事务的起点。
ROW 格式下事务边界还受 binlog_row_image 影响
binlog_row_image 参数控制每行变更记录哪些字段镜像，它不改变事务边界，但直接影响你能否还原出完整数据：
-
FULL：记录修改前后的全部字段值（默认），适合任意恢复场景 -
MINIMAL：只记录被修改字段 + 主键/唯一键（用于定位行），日志体积小，但恢复时若主键被删或更新，可能无法准确定位原行 -
NOBLOB：排除 BLOB/TEXT 字段，节省空间，但对含大文本的业务可能丢失关键信息
特别注意：MINIMAL 下，如果事务里先 UPDATE 主键再 DELETE 同一行，binlog 可能只记录 DELETE 的主键值，而没有原始行全量快照 —— 这时候靠 binlog 恢复就不可靠了。生产环境建议坚持用 FULL。
