mysqldump对加密表空间无效，因其仅导出明文SQL，不读取.ibd文件头及加密页，不备份密钥环与主密钥，恢复后无法重建ENCRYPTION='Y'状态且密钥不可用。
逻辑备份（如 mysqldump）无法保留加密状态，恢复后表空间默认不加密，且原密钥不可用——必须走物理备份路线。
为什么 mysqldump 对加密表空间完全无效
加密表空间（ENCRYPTION = 'Y'）的加密信息存在 .ibd 文件头和数据页中，mysqldump 只读取行数据并生成明文 SQL，跳过所有文件级元数据。它既不导出密钥环内容，也不记录表空间是否启用加密，更不会在 CREATE TABLE 语句里自动加上 ENCRYPTION='Y'。恢复后即使手动加该属性，也会因密钥缺失报 ER_TABLESPACE_CANNOT_ENCRYPT 或启动失败。
- 执行
SELECT NAME, ENCRYPTION FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE ENCRYPTION = 'Y'查到的加密表，在mysqldump --all-databases输出里找不到任何加密标识 - 即使你用
mysqldump --no-create-info --skip-triggers配合手动重建 DDL，也无法还原加密页结构或密钥绑定关系 -
mysqlpump同样是逻辑层工具，行为一致，不解决根本问题
物理备份必须同时捕获三类关键文件
加密表空间的可恢复性取决于三个组件原子一致：加密数据文件、密钥环文件、主密钥（尤其是 keyring_encrypted_file 场景）。缺一不可，顺序也不能错。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
.ibd、ibdata1、ib_logfile*、undo_*等实际承载加密数据的文件 —— 必须完整拷贝，不能只挑部分表空间 - 密钥环文件路径由
keyring_file_data（明文存储）或keyring_encrypted_file_data（加密存储）指定，例如/var/lib/mysql-keyring/keyring或/var/lib/mysql-keyring/encrypted_keyring—— 必须与 MySQL 实例运行时路径完全一致 - 若使用
keyring_encrypted_file，主密钥（如/etc/mysql/master.key）是独立二进制文件，MySQL 不管理其生命周期 —— 它必须在备份前已生成、权限设为600、且不在 MySQL 数据目录内
企业版用 mysqlbackup，社区版只能靠 xtrabackup-8.0 + 手动归档
mysqlbackup（MEB）是唯一被 MySQL 官方认证支持加密表空间物理备份的工具，但仅限企业版；社区用户必须用 Percona XtraBackup 8.0，并自行补全密钥环与主密钥的归档链路。
-
mysqlbackup命令示例：mysqlbackup --defaults-file=/etc/my.cnf --backup-dir=/backup/mysqlbak backup，它会自动识别keyring_*插件并打包密钥环文件到backup-dir/keyring/子目录 -
xtrabackup-8.0不识别密钥环配置，需额外执行：cp $(grep keyring_encrypted_file_data /etc/my.cnf | awk -F= '{print $2}' | tr -d ' ') /backup/mysqlbak/和cp /etc/mysql/master.key /backup/mysqlbak/ - 无论哪种工具，备份前必须确保：
innodb_fast_shutdown = 0（避免加密页未刷盘）、FLUSH LOGS（对齐 redo 日志）、且服务处于稳定写入状态（非主从切换中）
还原时加载顺序错误直接导致 MySQL 启动失败
MySQL 启动时，keyring_encrypted_file 插件会在 InnoDB 初始化前尝试解密密钥环文件。如果主密钥路径不对、权限错误、或密钥环文件版本不匹配，服务将卡在启动阶段，报错如 ER_KEYRING_ACCESS_DENIED 或 Operating system error number 13。
- 先还原主密钥文件到原始路径（如
/etc/mysql/master.key），执行：chown root:root /etc/mysql/master.key && chmod 600 /etc/mysql/master.key - 再还原密钥环文件到
keyring_encrypted_file_data指向路径，确认属主为mysql:mysql - 最后还原数据文件，并严格保持
server_uuid不变（否则 TDE 元数据校验失败）；若变更了 server_uuid，必须用mysqlbackup --apply-log-only或xtrabackup --prepare重新签名
最易被忽略的是主密钥的离线保管 —— 它不随 MySQL 实例启停而变化，一旦丢失，整个加密表空间永久不可解密。备份包里存一份不够，必须单独加密存入 Vault 或 HSM，并定期验证可读性。
