MySQL 日志不是“一种东西”，而是多个独立日志文件，各司其职、分属不同层级——Server 层（如
binlog、
error log）和 InnoDB 引擎层（如
redo log、
undo log）的日志完全不互通，配置方式、刷盘逻辑、甚至生命周期都不同。搞混它们，轻则查错绕路，重则主从数据不一致或崩溃后无法恢复。
怎么一眼区分 binlog、redo log 和 undo log？
这是开发和 DBA 最常混淆的三类日志，关键区别不在“有没有”，而在“谁写、写什么、什么时候用”：
binlog是 Server 层日志，所有引擎通用；记录的是逻辑操作（比如
UPDATE t SET x=1 WHERE id=5），用于主从复制和基于时间点的恢复（PITR）；它不参与崩溃恢复，事务提交后才写入（可配置为每事务刷盘）
redo log是 InnoDB 独有，物理日志，记录的是“某个数据页的第 N 个字节改成了什么值”；它在事务执行过程中就持续写入内存缓冲区（
innodb_log_buffer），再由后台线程或事务提交时刷到磁盘（
ib_logfile0、
ib_logfile1）；数据库 crash 后靠它重放未刷盘的脏页
undo log也是 InnoDB 引擎层日志，存储在共享表空间或独立 undo 表空间（
innodb_undo_directory）；它保存的是“旧值”，用于事务回滚和 MVCC 多版本读；不落磁盘文件，而是以段（segment）形式存在页中，由 purge 线程异步清理
一个
UPDATE执行时，三者协同但互不替代：先写
undo log（留退路），再改内存页并记
redo log（保持久），最后提交时记
binlog（供复制）——这就是两阶段提交（2PC）要协调的点。
哪些日志必须开？哪些建议关？
生产环境不是日志越多越好，而是按需启用，否则 I/O 压力陡增、磁盘爆满、甚至拖慢 QPS：
必须开：binlog（主从/备份依赖）、
error log（故障第一现场）、
slow_query_log（性能问题逃不开它） 建议开：
general_log（仅调试期临时开启，记录所有语句，性能损耗大） 默认关闭、慎开：
audit_log（需插件支持，审计合规场景才启用）、
relay_log（只在从库生效，主库无意义）
特别注意：
general_log开启后每条连接、每条查询都会落盘，QPS 上千时可能直接打满磁盘 IO；
slow_query_log的阈值别设成
0（等于全量记录），合理值是
long_query_time = 1.0（秒）起步，配合
log_queries_not_using_indexes = ON更实用。
怎么快速定位日志路径和当前状态？
别翻配置文件猜，用 SQL 和系统命令直接查：
SHOW VARIABLES LIKE 'log_error'; -- 错误日志路径 SHOW VARIABLES LIKE 'general_log%'; -- 查询日志开关和文件名 SHOW VARIABLES LIKE 'slow_query_log%'; -- 慢日志开关与路径 SHOW VARIABLES LIKE 'log_bin'; -- binlog 是否开启 SHOW VARIABLES LIKE 'innodb_log%'; -- redo log 文件数、大小、路径（如 innodb_log_group_home_dir） SELECT * FROM performance_schema.log_status; -- MySQL 8.0.30+ 可查所有日志刷盘位点
常见坑：
log_bin开启后，
server_id必须非零且唯一，否则启动报错
ERROR 2002 (HY000): Can't connect to local MySQL server（其实是初始化失败）
innodb_log_file_size修改前必须停库、删旧文件（
ib_logfile*），否则重启失败；且总大小（
innodb_log_files_in_group × innodb_log_file_size）建议为 2GB–4GB，太小导致频繁 checkpoint，太大延长 recovery 时间
binlog_format设为
STATEMENT时，
NOW()、
UUID()、自增主键等函数在主从上可能产生不同结果，强烈建议用
ROW
真正难的不是记住日志名字，而是在出问题时能立刻判断该看哪个日志：主从延迟？查
relay_log和
SHOW SLAVE STATUS；服务起不来？第一眼扫
log_error；update 提交了但查不到？得顺着
undo log版本链和
redo log刷盘状态去推——这些日志从来不是孤立存在的，它们的边界和协作关系，才是线上排障的底层地图。
