做过几年 MySQL 运维的人基本都逃不过“mysql 查看 binlog 日志”这个需求。不管是线上数据被误删了还是主从同步突然报错又或者就是想查一下某个时间点到底执行了什么 SQL最后都得翻 binlog。这玩意儿平时安安静静躺在数据目录里一旦出事它就是唯一的“黑匣子”能把操作记录一条条翻出来给你看。这篇文章我用自己的实操经验把 binlog 的查看方法、常见参数、典型场景和踩过的坑一次性讲清楚。内容不绕弯子直接上命令、上案例、上排查思路适合正在处理线上问题的开发、DBA 或者刚接触 MySQL 底层机制的运维新人。1. 先搞清楚 binlog 到底是什么很多人把 binlog 和 redo log 搞混这里先花两分钟把概念捋清楚。1.1 binlog 记录了什么binlogBinary Log是 MySQL Server 层维护的二进制日志记录的是所有“改变数据”的操作比如 INSERT、UPDATE、DELETE、CREATE TABLE、ALTER TABLE 等等。SELECT 这种只读操作不会写 binlog因为库里的数据没变从库也不需要同步这些查询。关键点在于binlog 是在 Server 层生成的也就是说不管你用 InnoDB、MyISAM 还是其他存储引擎只要开了 binlog它都会按顺序记录。而 redo log 是 InnoDB 存储引擎自己的日志记录的是物理页的修改主要用于崩溃恢复——掉电后把没刷盘的数据找回来。两者分工完全不同一个是逻辑日志记录 SQL 或行变化一个是物理日志记录页修改不能互相替代。一般生产环境 binlog 都默认开启因为它还承担着一个更重要的工作主从复制。主库把 binlog 发给从库从库拿过来重放从而实现数据同步。所以只要你的 MySQL 搭了主从架构binlog 一定是开着的。1.2 什么场景下你需要翻 binlog我和身边同事实际遇到过的场景主要有这几类误操作数据找回比如某天手抖执行了一条不带 WHERE 的 UPDATE或者 DELETE 删多了。这时候只能靠 binlog 把误操作前的数据捞回来。主从同步中断排查从库报错Coordinator stopped because there were error(s)之类的问题需要对比主库 binlog 和从库执行到哪个位置。审计某个时间段的操作比如怀疑某个时间点有人改了表结构或者想确认一条数据到底是什么时候被改的。增量备份恢复全量备份 从某个 binlog 位置开始重放这是最常规的恢复手段。简单说binlog 就是 MySQL 的“操作流水账”。出了问题你想知道“账上记了什么”就得会看这本流水账。2. 查看 binlog 前的准备工作看 binlog 本身不难但如果你连状态都没确认清楚很容易浪费时间。先去摸清几个基础情况。2.1 确认 binlog 开关和文件列表在 MySQL 命令行里执行SHOW VARIABLES LIKE log_bin; SHOW BINARY LOGS;第一条命令查看 binlog 是否开启返回值如果是ON说明开了。第二条命令列出当前所有 binlog 文件以及每个文件的大小类似这样------------------------------ | Log_name | File_size | ------------------------------ | mysql-bin.000001 | 177 | | mysql-bin.000002 | 456123 | | mysql-bin.000003 | 1024 | ------------------------------这里能看到文件名、大小方便你判断该翻哪个文件。文件命名一般是mysql-bin.000001这种格式前缀可以通过log-bin参数自定义后缀序号从 000001 开始递增。每次 MySQL 重启、或者当前文件达到max_binlog_size限制时就会滚动生成下一个序号的文件。如果log_bin是OFF那你没法查得先开启。怎么开下面说。2.2 没开启 binlog 怎么办有些开发环境的 MySQL 默认没开 binlog或者个人本地装的 MySQL 也没开。想开启的话修改配置文件my.cnf或my.ini在[mysqld]段下加server-id 1 log-bin mysql-bin binlog_format ROW然后重启 MySQL 服务。注意server-id必填即使单机也必须设置否则 MySQL 会拒绝启动 binlog 功能。log-bin指定 binlog 文件的前缀名称可以带路径比如log-bin /data/mysql/logs/mysql-bin。提示修改完配置一定要重启 MySQL 才能生效。生产环境没有重启窗口的话要考虑其他方案一般线上都是提前开好 binlog 的。2.3 binlog 格式选哪种ROW、STATEMENT 还是 MIXED这是个影响深远的选择直接决定你查看 binlog 时看到的内容。三种格式各有特点格式记录内容优点缺点STATEMENT记录原始 SQL 语句日志量小易读某些函数如 NOW()、UUID()在主从重放时可能结果不一致ROW记录每一行的变更前后值主从复制最安全能精确恢复日志量大直接看日志是一堆二进制要加参数才能还原成 SQLMIXED自动判断多数用 STATEMENT特殊场景切 ROW折中方案行为不够直观排查时不好预期我的建议很简单生产环境直接选 ROW。虽然日志文件体积涨得快但数据恢复时它最可靠能看到每一行数据“从什么值变成什么值”这在误删恢复场景里是救命级的特性。MySQL 8.0 默认就是 ROW 格式。这篇文章后面讲的查看命令也默认你用的是 ROW 格式。3. 实操查看 binlog 的四种主流方式环境确认完毕接下来就是核心部分。我从最常用的命令行工具讲起然后是按位置查看、SQL 层面查看、直接读文件这三种方式。3.1 方式一mysqlbinlog 命令行工具最常用mysqlbinlog是 MySQL 官方自带的工具它能把二进制日志解析成可读的文本格式输出。路径一般在 MySQL 安装目录的bin目录下比如/usr/local/mysql/bin/mysqlbinlog。最基本的用法mysqlbinlog /var/lib/mysql/mysql-bin.000003执行后会把整个文件的内容全部打印到终端。如果文件很大输出会非常长所以实际使用中基本都要加参数过滤。最常用的几个参数# 按时间范围过滤 mysqlbinlog --start-datetime2025-01-10 09:00:00 --stop-datetime2025-01-10 10:00:00 /var/lib/mysql/mysql-bin.000003 # 按位置范围过滤 mysqlbinlog --start-position157 --stop-position483 /var/lib/mysql/mysql-bin.000003 # 解析 ROW 格式还原成可读 SQL-v 显示注释信息-vv 再加字段类型信息 mysqlbinlog --base64-outputDECODE-ROWS -v --start-datetime2025-01-10 09:00:00 /var/lib/mysql/mysql-bin.000003这里有个关键经验ROW 格式的 binlog 内容默认以 base64 编码展示直接看是乱码。如果执行命令时不加--base64-outputDECODE-ROWS -v你屏幕上全是BINLOG ...这种字符串根本没法读。加了这两个参数工具会尽量还原出“伪 SQL”注释比如### INSERT INTO test.user ### SET ### 11 ### 2张三 ### 32025-01-10 10:30:00这种展示方式虽然不是标准 SQL但已经能很直观地看出这一行插入了什么数据。如果加了-vv还会额外显示字段名和类型排查时更好定位。另外如果不希望看到任何 base64 编码的原文就一定要带--base64-outputDECODE-ROWS它可以抑制直接打印 BINLOG 字段内容只输出解析后的行数据信息。3.2 方式二SHOW BINARY LOGS 和 SHOW MASTER STATUS这两个命令是 SQL 层的辅助命令不读取具体日志内容但它们帮你快速定位该查哪个文件、以及当前写到哪了。SHOW BINARY LOGS;前面刚提过用来列出所有 binlog 文件。SHOW MASTER STATUS;用来查看当前正在写入的 binlog 文件名和当前位置SHOW MASTER STATUS\G输出File: mysql-bin.000003 Position: 483 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set:这个信息在恢复数据时特别有用——你至少得知道“当前主库写到了哪个文件哪个位置”才能规划恢复的终点。3.3 方式三SHOW BINLOG EVENTS 直接在 SQL 层查看如果你不想切到命令行用mysqlbinlog也可以在 MySQL 客户端里直接查看 binlog 的事件内容SHOW BINLOG EVENTS IN mysql-bin.000003 FROM 483 LIMIT 10;这条命令会以表格形式展示从位置 483 开始的 10 个事件每行包含事件类型、开始位置、结束位置等信息类似----------------------------------------------------------------------------------------------------- | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | ----------------------------------------------------------------------------------------------------- | mysql-bin.000003 | 483 | Query | 1 | 579 | use test; INSERT INTO user VALUES... |这种方式适合快速预览不用离开客户端。但它的缺点是ROW 格式下Info列里显示的也是 base64 编码的 BINLOG 事件无法直接看到行数据变化。所以它更适合看 DDL 语句、事务边界这类结构性事件不适合看具体行数据。还有一个权限要求需要注意要执行SHOW BINLOG EVENTS账号至少要有REPLICATION SLAVE权限否则会报 access denied。3.4 方式四直接看二进制文件不推荐但要知道有同事习惯直接cat /var/lib/mysql/mysql-bin.000003或者tail -f然后看到一堆乱码就懵了。这是因为 binlog 本质是二进制文件包含了不可打印字符和特定格式的头部信息。cat只是把它当文本输出当然没法直接读。那能不能用strings命令凑合看可以但也只能捞到部分可读的字符串数据不完整还容易误导。比如 STATEMENT 格式下还能看到 SQL 片段ROW 格式下基本什么都看不出来。所以这种方式的定位是紧急情况下快速确认 binlog 里有没有某个关键词别指望它做精细排查。3.5 一个完整案例定位某段时间的误操作假设现在是下午业务方反馈上午 10:00 左右有一个订单状态被批量改错了我们需要在 binlog 里找到那几条 UPDATE。先列出文件SHOW BINARY LOGS;假设当前文件是mysql-bin.000005。执行mysqlbinlog --base64-outputDECODE-ROWS -v \ --start-datetime2025-01-10 09:55:00 \ --stop-datetime2025-01-10 10:05:00 \ /var/lib/mysql/mysql-bin.000005 /tmp/recover_order.sql然后把输出文件打开看找到UPDATE相关的段落确认变更前后的值。如果确认是误操作再用 mysqlbinlog 生成的 SQL 反推恢复语句。实操下来这套流程非常顺比在数据库里一条条SELECT找快得多。4. 数据恢复实战从 binlog 里把误删的数据“捞”回来查看 binlog 只是手段最终目的往往是恢复数据。这一节我用一个具体场景走一遍完整流程。4.1 恢复思路假设发生了这样的误操作上午 10:30 左右某张业务表user被执行了DELETE FROM user WHERE status 0结果删掉了 5000 行数据。你在 10:45 发现了问题想恢复。恢复思路是确认误删除的时间点也就是定位到 binlog 中那条 DELETE 事件。找到该 DELETE 事件在 binlog 中的具体位置position。把 DELETE 语句之前的数据变更从 binlog 中解析成一个新的 SQL 文件。在恢复库上执行该 SQL 文件把数据恢复到误操作前的状态。关键点在于你需要的并不是“重放”那批 DELETE而是要把 DELETE 语句本身转换为反向的 INSERT 语句。如果你只是重放 binlog那只会又执行一遍删除问题更严重。4.2 实操步骤第一步找到删除事件位置。执行mysqlbinlog --base64-outputDECODE-ROWS -v \ --start-datetime2025-01-10 10:20:00 \ --stop-datetime2025-01-10 10:40:00 \ /var/lib/mysql/mysql-bin.000005 /tmp/check.sql在/tmp/check.sql里搜索DELETE FROM定位到那条 DELETE 事件前后的# at position标记。假设 DELETE 事件的开始位置是 1847结束位置是 2100。第二步把这个 DELETE 之前的 binlog 片段导出也就是从起点位置到 1847 之前mysqlbinlog --start-position0 --stop-position1847 \ /var/lib/mysql/mysql-bin.000005 /tmp/recover_before_delete.sql第三步把导出文件在恢复库上执行mysql -u root -p /tmp/recover_before_delete.sql这样恢复库就回到删除前的状态了。注意这里有个前提你的 binlog 开启于数据创建之前或者全量备份之后没有中断否则 binlog 里根本没有这条数据的完整历史。4.3 开启 GTID 时的两个坑如果你用的是 MySQL 5.7 以上且开启了 GTID 模式gtid_modeON直接重放 binlog 会报错因为同一个 GTID 不允许重复执行。解决办法是导出时加--skip-gtidsmysqlbinlog --skip-gtids --start-position0 --stop-position1847 \ /var/lib/mysql/mysql-bin.000005 /tmp/recover_before_delete.sql这个参数的作用是忽略 binlog 里的 GTID 信息让目标库重新分配一个新事务从而正常执行。另一个坑是如果你的恢复目标是线上主库千万不要直接执行这种恢复 SQL最好先恢复到临时实例验证数据无误后再用业务手段把数据合并回去。直接在主库上回放 binlog 容易引发更多连锁问题比如主从冲突、自增主键重复等。我见过同事因为直接在主库上回放日志导致从库同步完全卡死最后花了几个小时才修好。注意大事务的 binlog 回放会锁表很长时间。如果误删的是特别大的表恢复前建议评估影响优先在业务低峰期操作。5. 常见问题与排查技巧实录我把这些年实际踩过的坑整理成一份速查按频率从高到低排。5.1 mysqlbinlog 命令找不到或版本不匹配新装的环境容易出现这个问题。原因一般是mysqlbinlog不在 PATH 环境变量里或者你用的是 MariaDB 自带的替代命令。排查方法which mysqlbinlog如果找不到就全盘搜一下find / -name mysqlbinlog -type f 2/dev/null找到后直接使用全路径比如/usr/local/mysql/bin/mysqlbinlog。如果本机没装客户端工具也可以远程拉取日志前提是主库开启了远程访问 binlog 的权限mysqlbinlog --read-from-remote-server --host192.168.1.100 --userrepl --passwordxxx mysql-bin.000005注意远程拉取需要账号有REPLICATION SLAVE权限且 MySQL 配置里bind-address允许远程连接。这个方式比较冷门但确实能在不登录主库的情况下拿到 binlog 内容。还有个更容易踩的坑MySQL 8.0 的mysqlbinlog版本和 MySQL 5.7 的 binlog 文件存在格式兼容问题。用新版工具解析旧文件的某些事件类型可能报错优先用和数据库同版本的工具。5.2 ROW 格式下看不到可读 SQL这个前面提到了再强调一次不加--base64-outputDECODE-ROWS -v你看到的是一堆BINLOG xxxx字符串。加上之后才能看到### INSERT INTO ...这种伪 SQL。补充一点细节-v和-vv的差别只在于显示字段注释的详细程度。如果只需要定位操作类型-v足够如果需要知道字段名和值类型用-vv。5.3 时间范围和实际写入对不上MySQL 的 binlog 时间戳记录的是执行事务提交那一刻的时间时区由服务器的time_zone和system_time_zone共同决定。如果你用--start-datetime过滤但结果为空可能是时区配置导致相差 8 小时或更多。一个比较快的确认方法先用SHOW BINLOG EVENTS看事件的大致时间再对比系统时间。也可以直接按 binlog 事件位置来过滤放弃时间过滤改用--start-position和--stop-position这样最精确因为位置和时间没有对应关系不受时区干扰。5.4 SHOW BINLOG EVENTS 提示权限不足报错长这样ERROR 1227 (42000): Access denied; you need (at least one of) the REPLICATION SLAVE privilege(s) for this operation解决方式是用管理员账号授予权限GRANT REPLICATION SLAVE ON *.* TO your_user%; FLUSH PRIVILEGES;日常开发账号如果只是查 binlog 事件这个权限足够。5.5 binlog 文件被清理了怎么办binlog_expire_logs_secondsMySQL 8.0或expire_logs_days5.7 及之前控制 binlog 自动清理周期。如果误操作发生在很久以前而文件已过期被 purge那这部分数据就真的找不回来了。唯一能做的就是用全量备份 更早的归档 binlog 来恢复前提是你有定期把 binlog 归档到其他存储。这个问题的根因还是备份策略生产环境建议 binlog 保留周期不得低于全量备份周期通常双倍以上。比如每周做一次全量备份binlog 至少保留 14 天。5.6 position 和 event 对不上有时候你在SHOW BINLOG EVENTS里看到的 Pos 和mysqlbinlog输出里的# at position不完全一致这是正常现象因为日志事件由多个子事件组成比如 GTID 事件、Query 事件、Xid 事件等不同工具的展示粒度不同。真正恢复时选一个“安全位置”比纠结精确位置更重要。安全的含义是这个位置在一个事务的边界上不会把半个事务拆开。怎么判断看SHOW BINLOG EVENTS里事件类型是不是Xid或Query这两个往往是事务提交边界。5.7 日志文件巨大查看时 CPU 和 IO 飙升binlog 动辄几个 GB 是常态。如果你直接mysqlbinlog整个文件机器负载会瞬间拉满。两个建议尽量用位置或时间参数缩小范围只解析需要的片段。输出重定向到文件而不是直接打印到终端否则终端缓冲也会拖慢速度。我在处理 5GB 级别的 binlog 时通常配合grep做二次过滤比如先查输出的 SQL 文件里有没有目标表名再精确定位。这样不用反复解析同一份大文件。6. 几个提升效率的小技巧除了上面这些标准操作还有些细节能让干活更顺手。6.1 把常用命令封装成脚本每次手敲一长串mysqlbinlog参数容易出错。我习惯在服务器上放一个简单脚本传入文件、开始时间、结束时间三个参数自动带上--base64-outputDECODE-ROWS -v#!/bin/bash # binlog_view.sh - 查看 binlog 的简化脚本 BINLOG_BIN/usr/local/mysql/bin/mysqlbinlog LOG_FILE$1 START_TIME$2 STOP_TIME$3 if [ -z $LOG_FILE ] || [ -z $START_TIME ] || [ -z $STOP_TIME ]; then echo 用法: $0 binlog文件 开始时间 结束时间 exit 1 fi $BINLOG_BIN --base64-outputDECODE-ROWS -v \ --start-datetime$START_TIME \ --stop-datetime$STOP_TIME \ $LOG_FILE保存后chmod x binlog_view.sh再配合时间参数调用的命令就简洁多了。6.2 用实际日志反推恢复 SQL在 ROW 格式下mysqlbinlog输出里明确标注了### DELETE FROM、### UPDATE、### INSERT INTO三种类型。恢复逻辑很简单DELETE 反推成 INSERT把删除前的值再插回去UPDATE 反推出反向 UPDATE把新值改回旧值INSERT 反推成 DELETE把插入的数据删掉具体操作上我一般把解析后的文件交给开发同事处理业务数据或者用小脚本把### 1value这种格式转成 SQL。如果行数不多手动改也行行数多就得写个临时脚本搞定这里不展开但思路就是字符串解析加规则替换。6.3 定期验证 binlog 可解析性很多 DBA 只检查 binlog 有没有在生成却没试过用mysqlbinlog解析它。真到恢复现场才发现工具报错或文件损坏那就太晚了。我给自己定的习惯是每周挑一个 binlog 文件跑一次mysqlbinlog --base64-outputDECODE-ROWS -v哪怕只看最后 100 行确认能正常解析输出。这个习惯帮我提前发现过一次磁盘坏道导致的 binlog 写入异常价值非常大。最后再分享一点体会binlog 查看这件事说到底是三个关键词位置、格式、工具。位置决定你从哪开始看、看到哪结束格式决定你看到的内容长什么样工具决定你解析的效率。把这三件事想清楚不管遇到什么样的恢复场景基本都能从容应对。另外有个心态建议不管多紧急的数据恢复场景拿到 binlog 之后千万别急着在生产库上直接回放。先在临时实例上把数据捞出来验证无误后再按业务规范合入线上。我见过太多次因为赶时间跳过了验证环节最后恢复出来的数据不对反而花了更长时间补救。慢一点稳一点结果会更干净。