企业官网建设流程全解析

响应网站建设,wifi客户管理系统管理,羽毛球赛事有哪些,橱柜设计师培训一、Redo Log#xff08;重做日志#xff09;#xff1a;InnoDB 事务持久性的保障1. 核心作用Redo Log 是 InnoDB 专属的物理日志#xff08;记录「数据页的修改内容」#xff0c;如 “页号 X 的偏移量 Y 写入值 Z”#xff09;#xff0c;核心解决两大问题#xff1a;…一、Redo Log重做日志InnoDB 事务持久性的保障1. 核心作用Redo Log 是 InnoDB 专属的物理日志记录「数据页的修改内容」如 “页号 X 的偏移量 Y 写入值 Z”核心解决两大问题事务持久性即使数据库崩溃重启后可通过 redo log 恢复未刷盘的脏页数据避免数据丢失减少磁盘 IO先写 redo log顺序写再异步刷脏页到磁盘随机写提升写入性能。2. 日志文件组Redo Log 由多个固定大小的物理文件组成默认 ib_logfile0、ib_logfile1可配置数量和大小形成环形缓冲区写满后覆盖旧日志已刷盘的部分可覆盖包含两个关键内存结构redo log buffer内存缓冲区事务执行时先写入此处避免直接写磁盘redo log file磁盘文件最终持久化的日志存储位置。3. 刷盘时机核心参数innodb_flush_log_at_trx_commit该参数控制 redo log buffer 刷写到磁盘的时机直接决定事务持久性三种取值对应不同策略参数值刷盘逻辑持久性性能适用场景0每秒将 redo log buffer 刷到 os cache再由操作系统异步刷到磁盘事务提交时不做任何刷盘操作最低崩溃可能丢失 1 秒内数据最高非核心业务、允许少量数据丢失的场景1默认事务提交时强制将 redo log buffer 刷到磁盘调用 fsync () 确保落盘最高符合 ACID 持久性最低核心业务、要求数据零丢失的场景如金融、支付2事务提交时将 redo log buffer 刷到 os cache操作系统每秒异步刷到磁盘中等崩溃仅丢失 os cache 中未刷盘的数据中兼顾性能与持久性的通用场景补充无论参数取值如何InnoDB 后台线程会每秒刷一次 redo log buffer 到磁盘避免数据积压。4. 关键特性顺序写redo log 文件是环形顺序写入比随机写数据页效率高 10 倍以上物理日志仅记录数据页的修改不记录 SQL 逻辑恢复速度快崩溃恢复数据库重启时InnoDB 会重做 redo log 中未刷到数据文件的修改保证数据一致性。二、Binlog二进制日志MySQL 服务器层的逻辑日志1. 核心作用Binlog 是 MySQL 服务器层的逻辑日志记录「SQL 执行的逻辑」如 “给 id1 的行的 name 字段赋值为‘张三’”与存储引擎无关MyISAM/InnoDB 均支持核心用途主从复制主库将 binlog 发送给从库从库重放日志实现数据同步数据恢复通过mysqlbinlog工具解析 binlog恢复指定时间段的数据审计记录所有数据修改操作便于追溯操作记录。2. 记录格式Binlog 支持三种格式各有适用场景STATEMENT基于语句记录执行的 SQL 语句日志体积小但对「非确定性 SQL」如含 NOW ()、UUID ()、自增列可能导致主从不一致ROW基于行默认记录行的修改前后状态如 “id1 的行name 从‘李四’改为‘张三’”主从一致性最高日志体积稍大MIXED混合模式自动选择 STATEMENT/ROW兼顾体积与一致性。3. 写入机制Binlog 是「事务提交时写入」事务执行过程中修改操作先缓存事务提交时一次性写入 binlog按事务顺序写入保证事务原子性刷盘参数sync_binlog默认 1取值 1 时事务提交强制刷盘0 时由操作系统异步刷盘N 时每 N 个事务刷一次盘。4. 与 Redo Log 的两阶段提交核心关联为保证 binlog 和 redo log 的数据一致性避免主从数据不一致InnoDB 事务提交采用「两阶段提交」准备阶段prepare事务执行完成InnoDB 将 redo log 刷盘状态标记为 prepare此时 redo log 已持久化但 binlog 尚未写入。提交阶段commitMySQL 服务器层将 binlog 刷盘通知 InnoDB 将 redo log 状态标记为 commit事务完成。崩溃恢复逻辑若崩溃发生在 prepare 后、commit 前重启后检查 binlog若 binlog 完整则提交事务若不完整则回滚事务两阶段提交核心目标保证 redo log 和 binlog 要么都成功要么都失败避免数据不一致。三、Undo Log回滚日志事务原子性与 MVCC 的支撑1. 核心作用Undo Log 是 InnoDB 专属的逻辑日志记录「数据修改前的状态」核心功能事务回滚事务执行出错时通过 undo log 恢复数据到修改前的状态保证事务原子性实现 MVCC多版本并发控制读取数据时通过 undo log 构建历史版本实现读不加锁快照读。2. 核心特性逻辑日志记录行修改的反向操作如插入行则记录删除更新行则记录回滚到旧值版本链每行数据的多个版本通过 undo log 形成版本链配合事务 ID 实现快照读回收机制undo log 并非永久保存当没有事务需要访问某个版本时后台线程会异步回收存储位置Undo Log 存储在 InnoDB 的 undo 表空间默认共享表空间可配置独立表空间。3. 与 Redo Log 的区别维度Redo LogUndo Log作用重做修改保证持久性回滚修改保证原子性 / MVCC日志类型物理日志数据页修改逻辑日志行修改的反向操作生命周期刷盘后可覆盖环形事务提交后保留按需回收写入时机事务执行中持续写入事务执行时随数据修改写入四、三大日志核心关联与小结1. 核心关联逻辑2. 总结Redo LogInnoDB 物理日志通过innodb_flush_log_at_trx_commit控制刷盘时机保障事务持久性是崩溃恢复的核心Binlog服务器层逻辑日志支持三种记录格式主从复制 / 数据恢复的核心与 redo log 配合通过「两阶段提交」保证一致性Undo LogInnoDB 逻辑日志支撑事务回滚和 MVCC是读不加锁的关键生命周期随事务版本访问情况动态回收三大日志分工明确redo log 保 “持久”binlog 保 “同步 / 恢复”undo log 保 “原子性 / 并发”共同支撑 MySQL 事务的 ACID 特性。3. 核心参数日志类型核心参数关键作用Redo Loginnodb_flush_log_at_trx_commit控制事务提交时 redo log 的刷盘策略Binlogsync_binlog binlog_format控制 binlog 刷盘时机和记录格式Undo Loginnodb_undo_tablespaces innodb_purge_threads控制 undo 表空间和回收线程