事务提交后才会写入binlog，确保主从复制和数据恢复的一致性；未提交事务不记录，ROLLBACK则无任何binlog输出。
在mysql中，事务提交与binlog记录之间存在紧密的关联。只有当事务成功提交时，对应的SQL操作才会被写入binlog（二进制日志），这是保证数据一致性和主从复制正常工作的关键机制。
事务未提交时binlog不会记录
在一个事务执行过程中，即使已经执行了INSERT、UPDATE或delete等操作，这些更改仅存在于当前会话的缓存中，并不会立即写入binlog。此时如果查看binlog文件，不会看到相关事件。
例如：
START TRANSACTION;
INSERT INTO users(name) VALUES (‘Alice’); — 此时还未写binlog
直到执行COMMIT之前，该操作对binlog没有影响。若此时执行ROLLBACK，不仅数据不会持久化，也不会有任何binlog输出。
事务提交触发binlog写入
当执行COMMIT语句后，mysql会将整个事务的操作以事件形式写入binlog（前提是启用了binlog并配置正确）。这些事件包括Query_log_event或Rows_log_event，具体取决于binlog_format设置。
写入流程如下：
- 事务提交前，变更记录在存储引擎层（如InnoDB redo log）和binlog cache中
- 提交时，先将binlog cache中的内容刷入binlog文件（由sync_binlog控制是否同步到磁盘）
- 随后InnoDB完成commit，释放锁并更新数据页
这种顺序是“先写binlog再提交InnoDB”的两阶段提交（2PC）的一部分，确保崩溃恢复时的一致性。
binlog写入依赖事务整体结果
binlog记录的是已提交事务的逻辑操作。如果一个事务包含多条语句，要么全部写入binlog，要么一条都不写（回滚情况下）。
举例说明：
START TRANSACTION;
UPDATE account SET balance = balance – 100 WHERE id = 1;
UPDATE account SET balance = balance + 100 WHERE id = 2;
COMMIT; — 这两条UPDATE作为一个事务单元写入binlog
如果中途发生错误或手动ROLLBACK，则这两条更新都不会出现在binlog中。
与隔离级别和autocommit的关系
当autocommit=1时，每条sql语句被视为独立事务，执行完成后自动提交，因此会立即写入binlog。
在autocommit=0或显式使用START TRANSACTION的情况下，必须显式COMMIT才能触发binlog写入。
不同隔离级别不影响binlog写入时机，只影响并发可见性。无论READ COMMITTED还是REPEATABLE READ，binlog都只记录已提交事务的操作。
基本上就这些。事务提交是binlog写入的触发点，这个设计保障了主从复制的数据一致性，也使得基于时间点的恢复成为可能。