MySQL 5.7 不支持 binlog_encryption——该功能自 MySQL 8.0.14 才引入，5.7 中变量不存在，配置无效，启动时静默忽略，运行时设置会报“未知系统变量”错误。
MySQL 5.7 根本不支持 binlog_encryption
直接说结论：binlog_encryption 在 MySQL 5.7 中完全不可用——不是配置错，是压根没这个功能。执行 SELECT VERSION() 返回 5.7.x 的话，SHOW VARIABLES LIKE 'binlog_encryption' 要么报错 Unknown system variable，要么查不到结果。即使你在 [mysqld] 段写了 binlog_encryption=ON，mysqld 启动时会静默忽略；运行时执行 SET GLOBAL binlog_encryption = ON 会报错 Variable 'binlog_encryption' is a read only variable，这其实是在告诉你：变量根本不存在，不是“只读”，是“未定义”。
MySQL 8.0.14+ 启用 binlog_encryption 的硬性条件
只有 SELECT VERSION() ≥ 8.0.14 才可能启用。但光版本达标远远不够，必须同时满足三项：
-
early-plugin-load=keyring_file.so（Linux）或early-plugin-load=keyring_file.dll（Windows），且必须写在[mysqld]段最前面 -
keyring_file_data=/var/lib/mysql-keyring/keyring，目录需提前创建、属主为mysql、权限设为0600 -
binlog_encryption=ON，同样只认[mysqld]段，不能写在[client]或其他段
缺一不可。漏掉 early-plugin-load，错误日志里会出现 Failed to initialize binlog encryption keyring 或 Keyring service not found，此时 SELECT @@binlog_encryption 仍返回 ON，但实际日志仍是明文。
mysqlbinlog 解析出乱码才是加密生效的标志
验证是否真加密，别看文件大小或错误日志有没有警告，直接试解析：
- 执行
mysqlbinlog /var/lib/mysql/mysql-bin.000001 - 如果输出全是不可读的二进制乱码、报错
Binary log is encrypted或Failed to decrypt event，说明加密已起效 - 如果还能清晰看到
INSERT INTO、UPDATE等明文 SQL，那一定没加密成功——常见原因是版本低于 8.0.14，或 keyring 插件没加载
注意：mysqlbinlog 本身不支持解密，它读出来就是加密后的原始流。想人工审计内容，得用配套密钥和专用工具，不是改个参数就能回退成明文。
加密后 binlog 的备份与恢复链路必须重设计
加密不是加个开关就完事。一旦启用 binlog_encryption=ON，所有依赖 binlog 的流程都得重新适配：
- 主从复制仍能自动工作（server 内部解密），但 DBA 无法再用
mysqlbinlog直接查看日志内容做故障排查 - 备份脚本若直接
cpbinlog 文件，备份的是加密数据，恢复时若密钥文件损坏或路径变更，这批日志永久不可读 - 归档系统若没集成 keyring 密钥管理，存下来的加密 binlog 就是废文件
- 审计平台若靠解析 binlog 做行为分析，必须升级到支持解密的版本，并确保密钥服务可用
最容易被忽略的点是：密钥文件 keyring_file_data 必须和 binlog 文件一样纳入备份范围，且权限、属主、路径三者必须严格一致，差一点就会导致整个加密链路失效。
