MySQL 的日志分析

---

---

MySQL 的日志分析

MySQL 的日志系统是保证数据一致性、持久性和高可用的核心组件，不同日志各司其职。以下是详细分类和解析：

---

一、事务日志（InnoDB引擎层）

1. Redo Log（重做日志）

• 物理格式：循环写入的固定大小文件（默认ib_logfile0、ib_logfile1）

• 核心作用：

  • 崩溃恢复：确保事务的持久性（Durability）
  • Write-Ahead Logging (WAL)：数据页修改前先写redo log

• 关键特性：

  • 顺序IO（比随机IO快）
  • 通过innodb_flush_log_at_trx_commit控制刷盘策略（1=每次提交刷盘，0/2=延迟刷盘）

• 工作流程

2. Undo Log（回滚日志）

• 存储位置：系统表空间（ibdata1）或独立undo表空间
• 核心作用：
  • 事务回滚：记录数据修改前的状态
  • MVCC实现：构建历史版本数据
• 生命周期：
  • 事务提交后不会立即删除（可能被MVCC引用）
  • 通过purge线程清理不再需要的undo日志

---

二、服务层日志

1. Binary Log（binlog）

• 逻辑格式：SQL语句或行变更（ROW格式）

• 核心作用：

  • 主从复制：从库通过重放binlog同步数据
  • 时间点恢复：配合全量备份恢复数据

• 关键参数：

  sync_binlog=1  -- 每次提交刷盘
  binlog_format=ROW  -- 推荐使用ROW格式
  

• 与Redo Log对比：

  特性	Redo Log	Binlog
  层级	引擎层实现	Server层实现
  内容	物理日志（页修改）	逻辑日志（SQL/行变更）
  写入时机	事务执行过程中持续写入	事务提交后一次性写入
  是否必须	仅InnoDB需要	所有引擎通用

2. Slow Query Log（慢查询日志）

• 记录条件：执行时间超过long_query_time（默认10秒）

• 分析工具：

  mysqldumpslow -s t /path/to/slow.log
  pt-query-digest /path/to/slow.log
  

3. General Log（通用日志）

• 危险操作：记录所有SQL语句（仅调试时开启，对性能影响极大）

---

三、其他重要日志

1. Error Log（错误日志）

• 关键信息：
  • 启动/关闭记录
  • 严重错误（Corrupt Table等）
  • 死锁检测信息（需设置innodb_print_all_deadlocks=ON）

2. Relay Log（中继日志）

• 复制专用：从库从主库拉取binlog后暂存为relay log，SQL线程重放

---

四、日志协同工作流程（以事务提交为例）

---

五、关注要点

1. 可靠性权衡：

   • innodb_flush_log_at_trx_commit=1 + sync_binlog=1（最高安全，性能最低）
   • 非金融场景可考虑设置为0或2提升吞吐量

2. 性能优化：

   • Redo Log文件大小建议设置4GB以上（避免频繁切换）
   • Binlog建议使用ROW格式+压缩（binlog_row_image=FULL）

3. 监控指标：

   SHOW STATUS LIKE 'Innodb_log_waits%';  -- redo log写等待
   SHOW BINARY LOG STATUS;  -- binlog写入位置
   

4. 灾难恢复：

   • 定期验证备份的binlog完整性（mysqlbinlog --verify）
   • 多副本场景建议开启binlog-checksum