直接看 mysqlbinlog 解析结果中 xid_log_event 的物理出现顺序，即为事务在 binlog 中的真实提交顺序；该顺序由组提交 flush stage 队列决定，严格对应磁盘字节流排列，与 sql 执行时间、commit 发出时间或事务开启时间无关。
怎么确认 binlog 里事务的实际提交顺序？
直接看 Xid_log_event 出现的物理顺序，就是事务在 binlog 中的提交顺序。MySQL 不会按 SQL 执行时间、COMMIT 语句发出时间或事务开启时间排序，而是严格按组提交（Group Commit）最终刷盘时的队列顺序落盘。
常见错误现象：两个事务 A 和 B，B 先 COMMIT、A 后 COMMIT，但 A 的插入时间更早 —— 此时 binlog 里仍是 B 在前、A 在后。这是因为顺序由 Flush Stage 队列决定，不是由 NOW() 或事务生命周期决定。
- 用
mysqlbinlog --base64-output=decode-rows -v mysql-bin.0000xx解析，逐行观察Xid = N的位置和前后事件（如Write_rows→Xid_log_event） - 每个事务块以
BEGIN（Query_log_event）起头，以Xid = xxx结尾；中间的Table_map+Write_rows属于该事务 - 不要依赖
show binlog events的输出顺序 —— 它只展示 event 类型和 position，不保证可读性；真正顺序必须靠mysqlbinlog解析后的文本流判断
为什么 show binlog events 看不出真实提交顺序？
show binlog events 是 MySQL 客户端命令，它从 binlog 文件中提取 event 元信息并格式化显示，但会跳过部分内部 event（如某些 Format_description_log_event），且不还原事务边界。更重要的是：它不解析 row 格式下的实际变更内容，无法关联 Write_rows 和其所属的 Xid。
使用场景：适合快速定位某个 position 是否存在 event，不适合做事务级顺序分析。
- 执行
show binlog events in 'mysql-bin.000005' limit 20只能看到 event 类型和 offset，看不到事务分组 - 如果 binlog_format 是
ROW，show binlog events不显示具体修改的字段值，也就无法判断哪个Write_rows属于哪个Xid - 真正可靠的顺序依据只能是
mysqlbinlog输出中Xid_log_event的出现次序 —— 它对应磁盘上字节流的真实排列
如何用 mysqlbinlog 快速比对两个事务的提交先后？
当你要验证某两个事务（比如修改同一张表的两条记录）谁先提交，最直接的方式是提取它们各自的 Xid，再查这两个 Xid 在解析结果中的相对位置。
- 先用
mysqlbinlog -v --base64-output=decode-rows mysql-bin.0000xx | grep -A 5 -B 5 "Xid ="找出所有Xid及上下文 - 结合
grep -n "Xid = 123"获取行号，比较两个Xid对应的行号大小 —— 行号小的先提交 - 注意：同一个事务可能有多个
Write_rowsevent，但只有一个Xid_log_event；务必以Xid为准，而不是任意一个Write_rows的位置 - 若遇到乱码或报错（如
unknown variable 'default-character-set=utf8mb4'），加--no-defaults参数绕过客户端配置干扰
容易被忽略的依赖参数：binlog_transaction_dependency_tracking
这个参数不改变 binlog 文件里 Xid 的物理顺序，但它会影响从库并行回放时对“哪些事务能并发执行”的判断。如果你在主库看到事务 A 在 B 前，但从库 replay 时 B 却先完成，问题很可能出在这里。
- 默认值是
COMMIT_ORDER：从库按Xid顺序串行回放，和主库完全一致 - 设为
WRITESET或WRITESET_SESSION时，主库会在 binlog 中额外写入last_committed和sequence_number字段，从库据此决定并行粒度 —— 但Xid的落盘顺序不变 - 关键点：无论该参数怎么设，
mysqlbinlog解析出的Xid物理顺序永远是主库真实提交顺序；只是从库“选择怎么用它”而已
