mysqlbinlog无法直接解析加密binlog，因其不读取密钥环且无解密能力；必须关闭binlog_encryption或通过--read-from-remote-server由MySQL服务端解密后获取。
mysqlbinlog 无法直接解析加密 binlog 的原因
MySQL 8.0.14+ 默认启用 binlog_encryption=ON 后，生成的 binlog 文件是 AES-256 加密的二进制数据。直接用 mysqlbinlog 读取会报错：Failed to open file 'mysql-bin.000001': Invalid argument 或输出乱码 —— 这不是路径或权限问题，而是工具根本没解密能力。
关键点在于：mysqlbinlog 本身不读取 MySQL 实例的密钥环（keyring），也不支持传入密钥文件。它只按原始 binlog 协议解析明文流。
必须先关闭 binlog 加密才能用 mysqlbinlog 解析
没有“绕过解密”的命令行技巧。想用 mysqlbinlog 查看内容，唯一可靠方式是临时停用加密：
- 确认当前状态：
SHOW VARIABLES LIKE 'binlog_encryption';返回ON就得处理 - 修改配置文件（如
my.cnf或my.ini），在[mysqld]段下添加：binlog_encryption=OFF - 执行
FLUSH BINARY LOGS;切换到新日志文件（旧加密日志仍不可读） - 重启 MySQL 实例（仅配置变更需重启；但
binlog_encryption是只读变量，必须重启生效）
注意：关闭加密后新产生的日志才是可解析的，历史加密文件依然无法恢复 —— MySQL 不提供离线解密工具。
替代方案：用 SHOW BINLOG EVENTS 在数据库内查明文事件
如果不能/不愿关闭加密，又需要快速定位某条 DML 的影响，SHOW BINLOG EVENTS 仍是可用的（它由 server 内部解密后返回）：
-
SHOW BINLOG EVENTS IN 'mysql-bin.000002' LIMIT 10;—— 查指定文件前 10 条 -
SHOW BINLOG EVENTS WHERE Log_name = 'mysql-bin.000002' AND Event_type = 'Query';—— 过滤 Query 类型（DDL/DML） - 注意：
SHOW BINLOG EVENTS不显示 row 格式下的具体字段值（如@1,@2），只显示语句模板和 table_id - 性能影响：大 binlog 文件上执行可能卡住连接，建议配合
LIMIT和已知 position 范围使用
真正需要解析加密日志时，只能靠 MySQL Server 自身
所谓“解析加密 binlog”，本质是还原出原始 SQL 或行变更。目前官方路径只有一条：让 MySQL 实例自己读取并转换成文本流。
操作步骤如下：
- 确保
log_bin_use_v1_row_events=OFF（默认），否则mysqlbinlog --base64-output=DECODE-ROWS -v会失败 - 用
mysqlbinlog加--read-from-remote-server参数，从运行中的实例拉取（要求有REPLICATION SLAVE权限）： mysqlbinlog --read-from-remote-server --host=127.0.0.1 --user=root --password --raw -r /tmp/raw.binlog mysql-bin.000002- 该命令会触发 server 端解密，再以原始格式写入本地文件（仍为二进制），但后续可配合
--base64-output=DECODE-ROWS -v解析
这个流程容易被忽略的是权限和网络配置：bind_address 必须允许本地连接，且用户要有 REPLICATION SLAVE 权限 —— 缺一不可。
