MySQL Binlog中事务起止边界以GTID_LOG_EVENT或首个行事件为起点、QUERY_EVENT（含COMMIT）为终点；可靠顺序依据是end_log_pos升序，而非event_time。
MySQL Binlog 本身不直接记录事务的“提交时间戳”，但可以通过 COMMIT 事件的位置（position）和时间（event_time）可靠判断事务提交的先后顺序——前提是 binlog 格式为 ROW 或 MIXED，且未启用 binlog_order_commits=OFF。
怎么看 binlog 中事务的起止边界？
每个事务在 binlog 中以 GTID_LOG_EVENT（启用 GTID 时）或 BEGIN 事件开头，以 QUERY_EVENT（含 COMMIT）结尾。中间穿插 WRITE_ROWS_EVENT、UPDATE_ROWS_EVENT 等行事件。
-
BEGIN事件不是必须存在（尤其在binlog_format=ROW下常被省略），不能依赖它定位事务起点 - 真正可靠的事务起点是上一个
COMMIT之后的第一个非空事件（如GTID_LOG_EVENT或第一个WRITE_ROWS_EVENT） - 事务终点一定是
QUERY_EVENT，其中query字段为COMMIT（注意：不是所有QUERY_EVENT都是 COMMIT，要检查内容） - 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析时，事务块会被缩进对齐，视觉上可辅助识别
为什么 event_time 有时不可靠？
event_time 是事件写入 binlog 缓冲区时的时间，受系统时钟、主从延迟、事务执行耗时影响，同一事务内多个事件的 event_time 可能相同或倒序（尤其高并发短事务场景）。
- 两个事务 A 和 B，若 A 先提交但写 binlog 稍慢，其
COMMIT事件的event_time可能晚于 B -
event_time在跨服务器（如主从不同机器）时无比较意义，仅适合单机内粗略参考 - 唯一权威顺序依据是
position：后提交的事务，其COMMIT事件的end_log_pos一定大于前一个事务的end_log_pos
如何用命令快速提取事务提交位置与时间？
用 mysqlbinlog 解析并过滤 COMMIT 事件，提取关键字段：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | \
awk '/^#.*at [0-9]+$/ {pos=$2} /COMMIT/{print pos, $1, $2}'输出形如：
# at 12345 #190101 10:20:30 server id 1 end_log_pos 12456 CRC32 0xabcde COMMIT /* xid=123 */
- 第一列是该事务第一个事件的起始
position（即# at XXX），第二列是event_time，第三列是end_log_pos - 按
end_log_pos升序排列，就是事务真实的提交顺序 - 若启用了 GTID，优先用
GTID_LOG_EVENT的gtid+ 后续COMMIT的end_log_pos组合定位，避免因 binlog rotate 导致 position 不连续
容易被忽略的坑：隐式提交和 DDL 的干扰
某些语句会触发隐式提交（如 CREATE TABLE、ALTER TABLE），它们自身就是一个独立事务，且不带 BEGIN，但仍有 COMMIT 事件；而显式事务中若混用 DDL，会导致当前事务被强制提交。
-
INSERT INTO t SELECT ...在binlog_format=STATEMENT下是单个QUERY_EVENT，无行事件，但仍以COMMIT结尾 -
TRUNCATE TABLE是 DDL，会隐式提交，其COMMIT事件紧跟在QUERY_EVENT后，容易误判为上一个事务的一部分 - 用
mysqlbinlog --include-gtids或解析GTID_SET可规避大部分隐式事务混淆，因为每个 GTID 对应唯一事务
真正要注意的是：不要只看有没有 BEGIN，而要看 COMMIT 事件是否成对、是否被 DDL 截断——这需要结合上下文 event type 和 position 连续性人工核验。
