xtrabackup的--compress和--encrypt不是“伪即时”，因其在拷贝innodb数据页时边读取、边压缩/加密、边写入，不生成未压缩/未加密中间文件，io与cpu流水线并行。
MySQL 8.0 本身不提供原生命令级的“即时压缩+加密”物理备份能力——mysqldump 是逻辑备份，无法处理加密表空间；mysqlbackup（MEB）虽支持，但仅限企业版；社区用户必须依赖 xtrabackup 8.0，并且它的压缩与加密是“备份过程中执行”，不是“写入时即时”，但效果等价于即时。
为什么 xtrabackup --compress 和 --encrypt 不是“伪即时”？
很多人误以为加了 --compress 或 --encrypt 就只是“事后打包”，其实不然：xtrabackup 在拷贝 InnoDB 数据页（.ibd）时，会边读取、边压缩/加密、边写入目标目录。整个过程不落地未压缩/未加密的中间文件，IO 和 CPU 是流水线式并行的。
- 压缩使用 ZSTD（默认）或 LZ4，比 gzip 更快、压缩率更高，且支持多线程：
--compress-threads=4 - 加密仅支持 AES256-CBC，密钥由
--encrypt-key提供，**必须与解密时完全一致**，无密钥即不可恢复 - 注意：
--encrypt不自动启用密钥管理，你得自己保管好这个字符串——它不是密钥环（keyring），和 MySQL 服务端的加密表空间无关
加密表空间（ENCRYPTION='Y'）能否用 xtrabackup 备份？
可以，但有硬性前提：xtrabackup **不接管 MySQL 的密钥环（keyring_file / keyring_encrypted_file）**。它只备份数据文件本身（已加密的 .ibd），不备份密钥上下文。
- 还原时，目标实例必须已加载相同的密钥环插件，且
keyring_file_data指向包含原始密钥的文件 - 如果你用的是
keyring_encrypted_file，主密钥（master_key_path）也必须提前部署好，否则启动会报Cannot decrypt tablespace -
xtrabackup不验证密钥环是否就绪，也不会报错——它只管拷文件。所以还原失败往往发生在启动 mysqld 阶段，而非 restore 阶段
压缩+加密组合命令怎么写才不出错？
最简可用命令要同时满足：指定配置文件、启用并行、显式声明压缩/加密参数、避免权限/路径陷阱。
- 必须用
--defaults-file指向正确的 MySQL 配置（如/etc/my.cnf），否则可能读错datadir或忽略 socket 路径 - 压缩与加密不能共用一个线程池，需分开设参：
--compress-threads=2 --encrypt-threads=2 - 加密密钥建议从文件读取，避免暴露在进程命令行中：
--encrypt-key-file=/etc/mysql/backup.key（该文件权限必须为 600，属主 mysql） - 示例全量命令：
xtrabackup \ --defaults-file=/etc/my.cnf \ --backup \ --target-dir=/backup/full_$(date +%Y%m%d) \ --user=bkpuser \ --password='xxx' \ --compress \ --compress-threads=3 \ --encrypt=AES256 \ --encrypt-key-file=/etc/mysql/backup.key \ --encrypt-threads=3 \ --parallel=4
注意：--encrypt=AES256 是固定写法，不是算法列表；--encrypt-key-file 内容必须是 32 字节（AES256）的二进制或 hex 字符串，可用 openssl rand -hex 32 > backup.key 生成。
最容易被忽略的三个细节
压缩和加密本身不难，但生产环境出问题基本都卡在这三点：
- 还原前没检查
keyring_file_data文件是否存在、权限是否为 mysql 可读——ls -l看一眼比 debug 两小时强 - 用了
--encrypt-key-file却忘了在 restore 后的prepare阶段也加同样参数，导致xtrabackup --prepare报错退出 - 误把
xtrabackup的加密当成 MySQL 表空间加密——前者保护备份文件，后者保护运行时数据；两者密钥体系完全独立，不能混用
