最常用方式是执行show master status;获取当前binlog文件名和逻辑位置；mysqlbinlog可解析本地或远程binlog，row格式默认不显示原始sql，但更可靠。
直接看当前正在写入的 binlog 文件名和位置
最常用也最快速的方式，是进 MySQL 执行 SHOW MASTER STATUS;。它立刻告诉你两件事：当前正在写的文件（File 列，比如 mysql-bin.000005），以及下一条日志将写入的位置（Position 列，比如 1234）。这个位置不是字节偏移，而是逻辑事件序号，后续用 mysqlbinlog 定位时必须对齐它。
注意：SHOW MASTER STATUS; 要求用户有 REPLICATION CLIENT 权限；如果返回空结果或报错 ERROR 1381 (HY000): You are not using binary logging，说明 binlog 根本没开——别急着解析，先去配 log-bin 并重启 mysqld。
用 mysqlbinlog 工具解析本地 binlog 文件
mysqlbinlog 是唯一能“读懂” binlog 二进制内容的官方工具，它把二进制事件转成可读的 SQL 或伪 SQL。关键点在于：它不能连数据库执行，而是直接读取磁盘上的 .0000xx 文件。
- 基础用法：
mysqlbinlog mysql-bin.000005 > events.sql，输出带注释的可读文本，含时间、position、SQL（或 row 变更） - 按位置截取：
mysqlbinlog --start-position=1234 --stop-position=5678 mysql-bin.000005，适合定位某次误操作前后 - 按时间范围：
mysqlbinlog --start-datetime="2026-01-28 14:20:00" --stop-datetime="2026-01-28 14:25:00" mysql-bin.000005，注意格式必须严格为YYYY-MM-DD HH:MM:SS - 常见坑：
mysqlbinlog默认不识别 row 格式里的表结构，若报Unknown table，加--base64-output=DECODE-ROWS -v强制解码并显示变更细节
远程拉取 RDS/PolarDB 的 binlog（不用登录服务器）
云数据库通常禁止直接访问数据目录，但支持通过网络协议远程读取 binlog。前提是：RDS 已开启 binlog（默认开启），且账号有 REPLICATION CLIENT 和 REPLICATION SLAVE 权限。
流程分三步：
① 先连上 RDS，执行 SHOW BINARY LOGS; 拿到想查的文件名（如 mysql-bin.000023）；
② 退出 MySQL，用本地 mysqlbinlog 发起远程请求：mysqlbinlog -u<code>your_user -p -hrds-host.mysql.rds.aliyuncs.com --read-from-remote-server --raw mysql-bin.000023 > remote.log
③ --raw 参数必须加，否则会尝试解析成 SQL 导致乱码；--read-from-remote-server 告诉工具走 MySQL 协议拉取，而非读本地文件。
注意：RDS 实例的 mysqlbinlog 版本最好与服务端一致（比如 RDS 是 MySQL 8.0.32，本地也用 8.0.x 的 mysqlbinlog），否则可能解析失败或漏事件。
为什么解析出来看不到原始 SQL？
这几乎必然发生——因为现代 MySQL 默认 binlog_format 是 ROW，它不记录 SQL 语句，只记录“哪张表、哪一行、从什么值变成什么值”。你看到的是类似 ### UPDATE `test`.`t1` ### WHERE ### @1=1 ### SET ### @1=2 的格式。
想看到原始 SQL，只有两种办法：
• 临时改格式（不推荐）：SET SESSION binlog_format = 'STATEMENT';，但这要求所有函数可确定、无非事务引擎、且主从环境允许；
• 用专业解析器（如 canal、maxwell 或阿里云 DTS）做语义还原，它们内部维护了表结构缓存和上下文映射。
真正需要审计或恢复时，ROW 格式反而更可靠：它不受 NOW()、UUID()、子查询等不确定性影响，不会出现主从不一致。别执着于“看到 SQL”，重点应是“确认哪几行被改了、改成什么样”。
