mysql binlog是server层二进制日志，按事务提交顺序记录已执行的变更事件，支持statement、row、mixed三种格式，通过sync_binlog控制刷盘，与innodb redo log通过两阶段提交保证一致性。
MySQL Binlog（Binary Log）是 MySQL 实现数据变更记录、主从复制和数据恢复的核心机制。它不是实时缓存日志，而是以事件（event）为单位，按事务提交顺序记录所有引起数据变更的 SQL 语句或行级变更，且仅记录已成功执行并提交的写操作。
Binlog 的三种格式：STATEMENT、ROW 和 MIXED
Binlog 日志内容的组织方式由 binlog_format 参数控制，不同格式影响日志体积、可读性、一致性与兼容性：
-
STATEMENT：记录原始 SQL 语句（如
UPDATE t1 SET a=2 WHERE id=1）。优点是日志小、可读性强；缺点是某些函数（NOW()、UUID()、USER()）、触发器、存储过程等可能导致主从不一致。 - ROW：记录每一行数据变更前后的镜像（before image / after image）。不依赖 SQL 执行上下文，能保证强一致性，支持并行复制和闪回；但日志体积大，尤其批量更新时，且不可直接阅读。
- MIXED：MySQL 自动在 STATEMENT 和 ROW 间切换——对确定性语句用 STATEMENT，对可能引发不一致的操作（如含函数、非事务引擎表）自动降级为 ROW。兼顾安全与效率，但行为不易预测，线上环境较少使用。
Binlog 的写入与刷盘时机
Binlog 不属于 InnoDB 引擎层，而是 Server 层日志，其生命周期独立于事务引擎。写入流程如下：
ShoopD 网上商店系统
下载
用 php + mysql 驱动的在线商城系统，我们的目标为中国的中小企业及个人提供最简洁，最安全，最高效的在线商城解决方案，使用了自建的会员积分折扣功能，不同的会员组有不同的折扣，让您的商店吸引更多的后续客户。 系统自动加分处理功能，自动处理会员等级，免去人工处理的工作量，让您的商店运作起来更方便省事 采用了自建的直接模板技术，免去了模板解析时间，提高了代码利用效率 独立开发的购物车系统，使用最
- 事务执行过程中，Server 层将变更操作生成 Binlog event，先写入线程私有 binlog cache（内存缓冲区）；
- 事务提交时，cache 中的内容被写入到 server 层的 binlog 文件（物理文件），该动作称为 write；
- 是否立即落盘（fsync）由 sync_binlog 参数决定：
–sync_binlog = 0：依赖操作系统定时刷盘，崩溃可能丢失日志；
–sync_binlog = 1：每次提交都强制 fsync，最安全，但有性能损耗；
–sync_binlog = N (N>1)：每 N 次提交同步一次，折中方案。
Binlog 与 InnoDB Redo Log 的关键区别
二者常被混淆，但定位与协作关系明确：
- Redo Log 是 InnoDB 引擎层日志，用于崩溃恢复（crash-safe），记录的是“物理逻辑日志”（如“某页某偏移处改为什么值”），循环复用，只对 InnoDB 表有效；
- Binlog 是 Server 层日志，面向逻辑变更，格式统一、可跨引擎（MyISAM/InnoDB 均记录），用于复制与归档，文件追加写，不覆盖；
- 两阶段提交（2PC）保障二者一致性：事务提交前，先写 Redo Log prepare，再写 Binlog，最后写 Redo Log commit。崩溃恢复时，MySQL 通过对比两者状态决定事务是否最终提交。
Binlog 文件管理与生命周期
Binlog 以二进制文件形式存在（如 mysql-bin.000001），配合索引文件（mysql-bin.index）跟踪当前活跃日志列表：
- 当单个 binlog 文件达到 max_binlog_size（默认 1GB）或执行
FLUSH LOGS/ 重启 MySQL 时，会滚动生成新文件； - 过期日志由 expire_logs_days（旧版本）或更精确的 binlog_expire_logs_seconds（8.0.28+）控制自动清理；
- 可通过
SHOW BINARY LOGS查看现有日志，SHOW BINLOG EVENTS IN 'xxx'查看具体内容（需权限），mysqlbinlog工具解析并重放日志。
