innodb_undo_log_encrypt和innodb_redo_log_encrypt需配合keyring插件且满足版本与初始化条件才能生效：前者可动态启用但仅加密新undo段，后者仅在首次初始化时生效；必须验证keyring激活、表空间encryption='y'及错误日志中“enabled”提示。
innodb_undo_logs_encrypt 和 innodb_redo_log_encrypt 是 MySQL 8.0.23+ 版本中启用 Undo/Redo 日志静态加密的两个关键开关，但它们不能单独生效——必须配合 Keyring 插件且满足前提条件。
必须先加载并验证 keyring_file 插件
MySQL 加密体系依赖 Keyring 统一管理主密钥，日志加密也不例外。没装好 keyring，这两个变量设成 ON 也会静默失效（错误日志里可能只报“keyring not ready”，不报错）。
- 确保配置文件
my.cnf的[mysqld]段包含：early-plugin-load=keyring_file.so keyring_file_data=/path/to/keyring/file
- 路径
/path/to/keyring/file必须由mysql用户可读写，且目录权限为750，文件权限为640 - 启动后执行：
SELECT * FROM information_schema.PLUGINS WHERE PLUGIN_NAME LIKE 'keyring%';，确认状态是ACTIVE - 执行：
SHOW GLOBAL VARIABLES LIKE 'keyring%';，确保keyring_operations值为ON
如果插件未激活，后续所有加密设置都无效。
innodb_redo_log_encrypt 和 innodb_undo_logs_encrypt 的行为差异
这两个变量看似对称，但实际约束不同：
-
innodb_redo_log_encrypt=ON：仅在 MySQL 实例首次初始化时生效（即 datadir 为空），一旦 redo log 文件已存在，该变量会被忽略，重启也不起作用 -
innodb_undo_logs_encrypt=ON：可在运行中动态开启（需先确保 undo 表空间是独立的，即innodb_undo_tablespaces > 0），但开启后新生成的 undo 段才加密，已有段保持明文
所以常见误操作是：
- 在已有生产实例上直接改配置并重启，发现 redo 日志没加密 → 因为 redo 文件已存在
- 开启
innodb_undo_logs_encrypt后查INFORMATION_SCHEMA.INNODB_TABLESPACES，发现 undo 表空间仍显示ENCRYPTION='N'→ 因为旧段未重用，新段还没被分配
如何验证加密是否真正生效
光看变量值或启动日志不够，得查底层状态：
- Redo 日志加密无法通过 SQL 直接查，只能用二进制方式验证（例如用
hexdump -C查看ib_logfile0开头是否有明显明文字符串，加密后通常前几十字节是随机乱码） - Undo 表空间加密可查：
SELECT SPACE, NAME, ENCRYPTION FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME LIKE 'undo%';，返回ENCRYPTION='Y'才表示当前活跃 undo 段已启用加密 - 错误日志中搜索关键词：
"Redo log encryption enabled"或"Undo tablespace encryption enabled"，注意不是“set”而是“enabled”
另外，若使用企业版 + keyring_okv 或 HSM，还需确认密钥后端通信正常，否则加密会卡在 keyring 初始化阶段。
最容易被忽略的兼容性限制
- 这两个加密开关仅在 MySQL 8.0.23 及更高版本支持；低于此版本即使配置了也不会报错，但完全无效
- 启用后无法降级到 8.0.22 或更低版本（因为加密日志格式不兼容）
- 若开启
innodb_redo_log_encrypt，备份工具如mysqlbackup（MEB）能识别并正确处理加密日志，但rsync或tar直接拷贝的物理备份，恢复时必须保证目标实例同样启用且 keyring 可用，否则启动失败 - 主从复制场景下，从库必须使用相同或更高版本，并同步开启对应加密参数，否则 IO 线程可能因无法解析加密日志而中断
真正落地时，别只盯着配置项开没开，重点盯住 keyring 是否就绪、日志文件是否重建、以及对应表空间元数据是否更新。
