MySQL六类日志核心原理：错误日志、慢查询日志、binlog与redo log-北京尧图网络

先说个场景。某天凌晨线上一个 MySQL 实例突然性能断崖式下跌CPU 用完连接数被打满。我接到电话后第一件事不是看监控而是打开错误日志和慢查询日志。十分钟定位到一条因为统计信息过期导致走错索引的 select立刻用FORCE INDEX救火再顺手做了一次ANALYZE TABLE。事后同事问我为什么能这么快我说MySQL 的日志就是它的飞行记录仪和黑匣子你平时不研究它出故障时它就给你颜色看。这篇文章我想把 MySQL 日志体系里最核心的六类日志一次讲透错误日志、慢查询日志、通用查询日志、二进制日志binlog、中继日志relay log、事务日志redo log 和 undo log。内容包括每类日志的产生原理、实际配置、查看方式和排障思路以及我这些年踩过的坑。适合刚接触 MySQL 的运维和开发也适合干了几年但一直对日志体系只有零散认识的人按这个框架把这六类日志串起来你会对整个数据库的运行机制有全新的理解。1. 先把六大日志的分工理清楚1.1 日志分层的本质很多人把 MySQL 日志当成“出问题才看”的东西这是最大的误解。要理解日志先要理解 MySQL 的分层架构。MySQL 大致分两层上面是 Server 层负责连接管理、SQL 解析、优化、执行下面是存储引擎层InnoDB 是默认引擎负责数据页的读写、事务、锁、崩溃恢复。日志也按照这个逻辑分。Server 层产生的日志包括错误日志、通用查询日志、慢查询日志、binlog存储引擎层产生的日志包括 redo log、undo log。这两个层面的日志解决的问题完全不一样Server 层日志记录“谁来了、做了什么、做得慢不慢”面向人排障用InnoDB 层日志记录“数据到底怎么改、改了之后怎么保证不丢”面向机器恢复用。搞清这个分层很多模糊的概念会自动清晰。比如 binlog 在 Server 层不管用什么存储引擎都有redo log 在 InnoDB 层换成 MyISAM 就没有。所以“没有 binlog 能不能恢复数据”“redo log 能不能删”这类问题的答案往下看自然就有了。1.2 一张表看懂六类日志我习惯用下面这张表快速向新人讲清楚六类日志的定位建议你也保存一份遇到问题先想想它属于哪一层、由谁产生、该看哪份日志。日志类型产生位置默认状态记录内容核心用途错误日志 error logServer 层开启启动、运行、复制过程中的错误信息排障第一入口通用查询日志 general logServer 层关闭所有客户端请求和 SQL调试、审计慢查询日志 slow logServer 层可配置开启超过执行阈值的 SQLSQL 性能优化二进制日志 binlogServer 层需配置开启数据变更的逻辑或行级记录主从复制、时间点恢复中继日志 relay logServer 层从库自动开启从主库拉取的 binlog 事件主从复制中转事务日志 redo/undoInnoDB 层自动管理重做记录、回滚记录崩溃恢复、事务回滚、MVCC记住这张表之后再往下看每个日志的具体操作。实际操作中你 80% 的排查工作会集中在错误日志、慢查询日志和 binlog 上剩下两类日志是你理解 InnoDB 事务和主从复制的根基绕不开。2. 错误日志与通用查询日志最容易被忽略的“现场记录仪”2.1 错误日志启动失败和运行异常的第一现场错误日志是 MySQL 默认就开的记录启动、停止、运行中的错误比如端口冲突、权限不足、表损坏、主从复制异常、InnoDB 恢复失败。出问题第一步永远是看它。启动报错时最常见的操作是tail -50 /var/log/mysql/error.log比如端口被占用时错误日志里会出现Cant start server: Bind on TCP/IP port: Address already in use数据目录权限不对时会出现Permission deniedInnoDB 数据文件损坏时会出现[ERROR] InnoDB: Database page corruption on disk。配置项是log_error可以指定文件路径也可以指定到系统日志。生产环境建议独立文件方便轮转和检索。8.0 版本里还有log_error_services可以控制错误日志的过滤和格式比如把错误日志格式化成 JSON方便日志采集系统接入。不过对绝大多数场景默认格式就够用。踩过的坑曾经有台服务器/分区写满mysqld 启动时报Disk is full writing ./ib_logfile0但你以为只是普通报错清理了些无用文件却发现 MySQL 仍然启动不了。实际上错误日志也写不进磁盘了会有部分日志丢在校验环节。后来我把错误日志单独放到一个分区数据目录另一个分区避免“日志把磁盘写满”和“日志无法写入导致故障排查盲区”这种雪上加霜的情况。2.2 通用查询日志所有请求的“监控录像”通用查询日志和慢查询日志不一样它不关心性能它记录“每一个发到 MySQL 的请求”包括连接建立、断开、每一条 SQL 的原文。默认关闭因为记录量极大生产环境开启会显著增加磁盘 IO。但是它在两类场景里特别有用。一是排查“开发框架到底发了什么诡异 SQL”比如应用日志里没打印 SQL你怀疑 ORM 有错误逻辑打开 general log 看几分钟所有请求原形毕露。二是审计场景某个账号半夜执行了什么操作general log 全部有记录。临时开启方式SET GLOBAL general_log ON; SET GLOBAL general_log_file /var/log/mysql/general.log;用完立刻关掉否则日志文件会在几小时内涨到几十 GB。我见过有同事开了 general log 忘记关第二天磁盘报警那个时候日志文件甚至比整个数据目录还大。注意 general log 记录的是文本 SQL可能包含业务敏感信息导出和分析时注意脱敏。2.3 一个磁盘满的排查实例有一回主库写入报错ERROR 3 (HY000): Error writing file我通过错误日志看到No space left on device。磁盘满时第一反应不是删数据文件而是看哪些日志可以安全清理。当时定位到三个大文件binlog 几十 GB、慢查询日志几个 GB、错误日志也几个 GB。处理顺序是先确认没有从库在拽旧 binlog然后PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 DAY清理过期 binlog再重命名慢查询日志和错误日志并用FLUSH LOGS重新创建。全程业务无感知磁盘马上释放。这就是为什么日志分类清晰很重要——同样名字都是“日志”有的可以放心删有的删了会出大事故。3. 慢查询日志SQL 性能优化的第一抓手3.1 从零开启慢查询日志的完整配置慢查询日志是性能排查里用得最多、最直接的日志。它专门记录执行时间超过阈值的 SQL阈值由long_query_time控制单位是秒。最简单的开启方式SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1; SET GLOBAL log_queries_not_using_indexes ON;注意三个坑long_query_time修改后当前已连接的会话不生效必须新建连接才会用新值long_query_time最小可设到 00 表示记录所有 SQL非特殊调试不要这么干log_queries_not_using_indexes会把没有走索引的 SQL 也写进去这个参数开启后慢日志量可能急剧增加但能帮你发现大量被隐藏的烂 SQL。如果要持久化写进 my.cnf[mysqld] slow_query_log 1 slow_query_log_file /var/log/mysql/slow.log long_query_time 1 log_queries_not_using_indexes 1重启后生效。线上实例建议用SET PERSIST而不是直接改 my.cnf避免重启时配置被覆盖。8.0 的SET PERSIST slow_query_log ON会写入mysqld-auto.cnf即使实例重启也仍然保留。3.2 慢查询日志的两种分析姿势慢查询日志里每一条 SQL 都包含执行时间、锁等待时间、扫描行数、返回行数。比如下面这条# Query_time: 2.500 Lock_time: 0.000 Rows_sent: 10 Rows_examined: 1000000 SET timestamp... SELECT * FROM orders WHERE user_id123 AND status1;Query_time2.5 秒Rows_examined100 万Rows_sent只有 10说明这条 SQL 扫描了太多行极可能缺联合索引。分析时不能只看Query_time重点看Rows_examined和索引使用情况。系统自带mysqldumpslow可以简单聚合mysqldumpslow -t 10 /var/log/mysql/slow.log按总耗时取前 10 条。如果你要更详细的分析建议用 Percona Toolkit 的pt-query-digestpt-query-digest /var/log/mysql/slow.log slow_report.txt它会自动把同类的 SQL 聚合到一起按总耗时、平均执行时间、出现次数排序还能看每个 SQL 的响应时间分布。我平时定位线上慢 SQL都是先跑这个工具再针对 Top 5 逐条看执行计划效率比手动翻日志高一个量级。3.3 慢查询日志容易踩的坑第一个坑是日志轮转。慢查询日志一旦开启文件会不停变大很多文章推荐直接把日志文件删掉但 MySQL 进程还持有旧文件句柄你删了以后空间不会释放新日志也写不进去合理的位置。正确做法是重命名日志文件然后执行FLUSH LOGS让它重新创建新文件。第二个坑是主从环境里在主库开log_queries_not_using_indexes会产生大量日志如果从库也同步配置两边的慢日志都会剧增。更严重的是主库慢日志写盘占用了 IO可能让本来就慢的 SQL 雪上加霜。开启后要观察磁盘 IO 和Slow_queries状态值发现异常及时调整阈值。第三个坑很隐蔽有很多查询本身执行时间不长但频繁调用每秒几千次单次 0.1 秒累计对 CPU 的消耗非常可观。慢查询日志默认只认单条执行时长抓不到这类高频短查询。要看这类问题我建议结合 performance_schema 的events_statements_summary_by_digest看总的调用次数和平均延迟把慢日志和 performance_schema 结合起来用才不会被单条慢 SQL 带偏了方向。4. 二进制日志与中继日志主从复制和数据恢复的生命线4.1 binlog 三种格式生产环境为什么必选 ROWbinlog 是 MySQL 里最关键的日志之一它记录所有数据变更操作主从复制靠它基于时间点恢复靠它很多数据同步工具也靠它。binlog 有三种格式这里我直接说结论生产环境用 ROW不要跟着老教程继续用 STATEMENT。格式记录内容优点缺点STATEMENTSQL 语句原文日志量小非确定性函数、limit 删除等易导致主从不一致ROW每一行数据变更前后的值最精确、可回溯日志量大MIXED自动选择 STATEMENT 或 ROW兼顾两者存在意外切换行为不可控为什么 STATEMENT 危险举个经典例子主库执行DELETE FROM t WHERE id100 LIMIT 1如果主从数据原本就略有差异从库执行这条 SQL 删掉的可能是另一行。再比如UUID()、NOW()这类函数每台机器的执行结果都不同复制到从库就会不一致。ROW 格式不记录 SQL 原文而是记录“某一行被改成了什么”主从执行结果必然一致。MySQL 8.0 默认已经是 ROW 格式。查看当前格式SHOW VARIABLES LIKE binlog_format;解析 ROW 格式 binlog 时直接看是看不懂的要这样用 mysqlbinlogmysqlbinlog --no-defaults --base64-outputDECODE-ROWS -v mysql-bin.000123加-v之后会显示### UPDATE \db.t 这样的伪 SQL展示每一行的变更前值和变更后值极其直观。这个参数我一年得用几百次强烈建议记下来。4.2 binlog 管理保留时间、自动清理与手动清理binlog 会一直累积所以必须设置保留时间。8.0 用参数控制SET GLOBAL binlog_expire_logs_seconds 86400;保留 24 小时。手动清理用PURGEPURGE BINARY LOGS TO mysql-bin.000123; PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;这里有一条铁律不要直接用rm删除 binlog 文件。binlog 的索引文件会记录所有现存 binlog 文件名你手动删了文件MySQL 启动或复制时发现索引里的文件不存在会报错。正确姿势永远是使用PURGE命令。判断 binlog 能不能删必须确认三点一是没有从库还在使用要删的 binlog可以用SHOW REPLICA STATUS看Relay_Master_Log_File字段二是保留时间满足备份策略比如每天凌晨做全备binlog 至少保留一个全备周期否则全备之后到当前时刻的数据变更没法补三是数据同步工具阿里 Canal、Flink CDC、canal 类的程序是否还依赖旧 binlog它们的位点也需要提前核对。我曾经因为只看主库、没看从库位点就 PURGE导致从库复制断了好几个小时最后靠重新备份恢复那叫一个狼狈。4.3 中继日志复制链路里最容易忽略的一环relay log 只在从库上存在。主从复制的原理是从库的 I/O 线程把主库 binlog 拉下来写入本地 relay log然后 SQL 线程读取 relay log 并执行。所以 relay log 本质上就是“复制链路上的中转站”。第一次搭主从复制的人经常盯着主库的 binlog 看半天却忘了从库的 relay log。实际上复制的延迟和中断很多问题都出在 relay log 这一环。排查从库状态的基本命令SHOW REPLICA STATUS\G重点看Replica_IO_Running、Replica_SQL_Running、Last_IO_Errno、Last_SQL_Errno这几个字段。如果Replica_SQL_Running为 Norelay log 可能一直在堆积I/O 线程还在继续拉主库日志最终把从库磁盘塞满。参数relay_log_recovery建议打开它能让从库在崩溃重启后丢弃没有执行完的 relay log重新从主库拉取避免因 relay log 损坏导致复制异常。处理 relay log 堆积的正确流程是先解决 SQL 线程报错再清理不要一上来就删 relay log否则会丢失尚未执行的复制事件。只有当你确认从库已经不需要恢复、准备重新搭建复制的极端情况下才用RESET REPLICA ALL重置整条链路。5. 事务日志redo log 与 undo log 为什么是 InnoDB 的命根子5.1 redo log先写流水账崩溃也能重放redo log 解决的核心问题是“已提交事务的数据不能丢”。InnoDB 的数据是存在磁盘上的但修改发生在内存 Buffer Pool 中。如果每次修改都立刻写回磁盘随机写性能会低到没法用所以 InnoDB 采用 WALWrite-Ahead Logging机制先把修改记录到 redo log再慢慢把脏页刷回磁盘。我用记账来打比方。公司每天大量收支会计不会每笔业务都立刻翻总账改数字而是先记在流水账本上晚上再统一誊到总账。如果中途账本烧了靠流水账还能重新誊一遍。redo log 就是这个流水账不过它记录的是“哪个数据页的哪个位置被改成了什么”是物理级别的日志。redo log 是循环写入的文件大小固定写满后会触发脏页刷盘推进 checkpoint。MySQL 8.0.30 之前用innodb_log_file_size和innodb_log_files_in_group配置默认是两批每批 48MB8.0.30 之后统一为innodb_redo_log_capacity默认 100MB可以动态调整。redo log 太小会导致频繁刷脏页写性能下降太大会让崩溃恢复时间变长。我个人的调优经验是从默认值开始观察SHOW ENGINE INNODB STATUS里的redo log write相关状态如果日志写入很频繁且每次写入量都接近容量就调大。崩溃恢复是怎么发生的MySQL 启动时会比较数据页的 LSN 和 redo log 里记录的 LSN凡是已经写入 redo log 但还没刷到数据页的修改就重新放一遍。这样即使断电已提交事务的数据也不会丢。5.2 undo log回滚和 MVCC 都靠它undo log 和 redo log 正好相反redo log 记录“改成了什么”undo log 记录“改之前是什么”。事务回滚时InnoDB 通过 undo log 把数据恢复成修改前的样子更重要的是MVCC 多版本并发控制也靠 undo log。其他事务做普通查询时如果需要读取历史版本的数据就从当前版本沿着 undo log 构建出旧版本。同样可以用生活类比redo log 像微信聊天记录里的“对方撤回了一条消息”之后的重新补发机制数据能恢复undo log 更像文档编辑器的撤销历史一步一步往前倒还能看到每个历史版本。实际运维中长事务是 undo log 的最大杀手。一个事务长时间不提交它创建的 undo log 就不能被 purge 线程清理undo 表空间会一直膨胀。表现是磁盘占用不断上涨但你又不能随便 kill 这个事务因为它可能正在执行大查询或者锁定重要数据。排查长事务用SELECT * FROM information_schema.innodb_trx\G看trx_started和trx_rows_modified找到启动时间最早、修改行数最多的事务再定位到具体会话去处理。8.0 默认使用独立的 undo 表空间支持自动截断开启innodb_undo_log_truncate可以帮助回收。5.3 两阶段提交redo log 和 binlog 的一致性锁前面说了redo log 在 InnoDB 层binlog 在 Server 层两者都会在事务提交时写入。如果不协调好会出现一个极端但必须避免的情况binlog 里有这条 SQL但 redo log 里没有或者反过来。主从复制和崩溃恢复时两个日志各说各话数据库就乱了。InnoDB 用两阶段提交解决这个问题。事务提交时先写 redo log 并标记为 prepare 状态然后写 binlog最后再写 redo log 并标记为 commit 状态。崩溃恢复时如果发现 redo log 是 prepare 状态就去查 binlog 里有没有对应的记录有则说明事务已经完整写入 binlog认为它已提交没有则回滚。这套机制保证了 binlog 和 InnoDB 数据的一致性主从复制链路上每个从库看到的数据变更才不会有缺口。参数上控制刷盘节奏的是innodb_flush_log_at_trx_commit和sync_binlog。两者都设成 1是最安全的配置每次事务提交都把 redo log 和 binlog 刷到磁盘性能损耗最大网络环境和磁盘可以接受的话我建议保持这个配置。如果追求性能可以把innodb_flush_log_at_trx_commit设为 2表示每秒刷一次盘性能提升明显但极端断电可能丢失最后一秒的事务这个 trade-off 一定要想清楚。6. 日志相关的常见问题与排查经验6.1 日志文件过大、删不掉怎么办日志过大的问题几乎每个 MySQL 实例都会遇到。我按日志类型给一套标准处理流程慢查询日志、错误日志、通用查询日志都是文本日志可以先mv重命名再执行FLUSH LOGS让 MySQL 重建新文件binlog 用PURGE BINARY LOGS BEFORErelay log 先确认复制正常再处理不要硬删。很多人在 binlog 上出问题都是因为误信了“直接删除 .000001 文件就能释放空间”的说法。真删了之后MySQL 启动时检查 binlog 索引或者复制读取时发现文件不存在错误日志直接报Could not find first log file name in binary log index。而且你自己手动删过的文件用PURGE命令也没办法修复索引只能把对应条目从 index 文件里手工剔除风险极高。所以说到底binlog 清理认准PURGE。如果是从库重启后一直报 relay log 相关错误优先检查relay_log_recovery有没有开启。打开这个参数后从库启动时会自动丢弃旧 relay log 并重新拉取能省去很多人工处理的时间。6.2 主从复制异常时怎么快速定位复制异常是 DBA 最常遇到的事故之一。快速定位的路径我总结为三步第一步看SHOW REPLICA STATUS\G确认Replica_IO_Running和Replica_SQL_Running的状态。IO 线程断了大概率是网络问题或者主库 binlog 被清理从库的位点缺失SQL 线程断了大概率是正在执行的 SQL 在从库上报错比如主键冲突、表不存在。第二步看错误日志。复制错误往往会同步写到 MariaDB 容器、监控系统等其实错误日志就在 error log 里直接tail -100 error.log通常能找到Got fatal error 1236之类的原因。Got fatal error 1236经常对应“从库请求的 binlog 位点已经不在主库上”这时需要重新对齐主从数据从库几乎不可能从断点自动恢复。第三步看Performance_schema里的复制线程表SELECT * FROM performance_schema.replication_applier_status_by_worker\G能精确看到 SQL 线程在哪个 GTID、哪个事务上报错。处理完报错原因后执行START REPLICA恢复。千万不要一上来就RESET REPLICA ALL重建那会丢掉从库已经应用的事务轻则重新初始化重则引发数据不一致。6.3 我用得最多的几条排障经验文章最后分享几条我在实际维护中沉淀下来的经验。五六年下来我发现日志排障最大的敌人不是“看不懂日志”而是“不知道这份日志属于哪一层、解决什么问题”。熟悉六类日志的分工后故障处理速度会有质的提升。日常巡检我习惯重点看三个信号一是错误日志里有没有 InnoDB 报错和复制报错它们是最严重的前置信号二是慢查询日志的 Top 10 有没有出现新的 SQL 模式很多性能恶化都是缓慢累积的三是 binlog 的保留时间与备份策略是否匹配这决定了你数据恢复能力的底线。一个小习惯救过我很多次每次修改日志相关参数都要用SHOW VARIABLES确认生效同时把配置写入 my.cnf 或SET PERSIST。光用SET GLOBAL修改而忘记持久化实例重启后配置会静悄悄回到旧值等你下次排查同一个问题时才发现参数根本没生效白白浪费几个小时。另外线上日志文件的权限也值得注意。mysqld 用户对日志目录必须有写权限否则启动或轮转时会莫名失败。很多权限问题在错误日志里只会反馈一句Permission denied跟数据目录权限混在一起不看上下文很容易走弯路。日志系统是整个 MySQL 生态里最基础也最强大的一部分。把它研究透不只能救急还能让你理解事务原理、复制机制、性能优化的底层逻辑。希望这篇梳理能帮你把这六类日志彻底串起来下次遇到线上问题的时候心里有底手里有招。

MySQL六类日志核心原理：错误日志、慢查询日志、binlog与redo log

相关推荐

Agent-Reach CLI实战：Python构建AI Agent的架构设计与避坑指南

基于Qwen3-VL-Embedding-8B的语义文搜图系统实践

text-to-cad 实战：从自然语言到 STEP、URDF、G-code 的参数化生成流水线

更多资讯

豆包AI助手进阶指南：从聊天到系统清理与Skill自定义

大厂Java面试实录：Spring Boot自动配置与分布式架构的深度追问

豆包AI助手全攻略：网页版、API、技能与清理电脑指令实测

Linux与数据库：工业数字化底座的选型与实战经验

半导体行业知识库建设实战：从RAG架构到2026现网版

FPGA SerDes设计实战：从GT Transceiver架构到高速接口调试全流程

今日更新

基于sEMG与IMU的手语手势识别：从数据采集到实时部署避坑指南

装配车间MES落地指南：SimpleMES工单流转、BOM与齐套检查实战

AI获客怎样减少重复线索？意客AI的原文复用与版本筛选

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？