流式压缩备份本质是xtrabackup输出经管道交由zstd/lz4等外部工具压缩，MySQL 8.0下默认压缩算法为zstd，且--stream与--compress互斥，必须用| zstd -T0 > backup.xbstream.zst类管道实现，还原需先解压再xbstream解包，并确保BACKUP_ADMIN权限、xbstream可用及多线程解压支持。
流式压缩备份不是“边备份边传到远端”那么简单，它本质是把 xtrabackup 的输出通过管道交给压缩工具（如 zstd 或 lz4），再重定向到文件或远程进程，从而省去中间临时目录的磁盘占用。MySQL 8.0 下必须注意：默认压缩算法已从 qpress 切换为 zstd，且 --stream 模式下不能直接用 --compress，得靠外部命令接管压缩逻辑。
流式备份命令必须加 --stream 且禁用 --compress
很多人卡在这一步：写了 --compress --stream=xbstream，结果报错 Option 'compress' cannot be used together with 'stream'。这是因为流模式下压缩必须由管道外置完成——xtrabackup 只负责把原始备份数据按 xbstream 格式吐到 stdout，压缩交给你自己选。
-
--stream=xbstream是唯一支持的流格式（MySQL 8.0 不再支持tar流） - 压缩必须用
| zstd -T0 > backup.xbstream.zst这类管道链，-T0表示自动使用所有 CPU 核心 - 若用
lz4，命令末尾换成| lz4 > backup.xbstream.lz4，注意不要加-z参数（lz4默认压缩） - 务必指定
--defaults-file=/etc/my.cnf，否则xtrabackup可能读不到datadir路径，导致备份空目录
还原时先解压再 xbstream 解包，顺序不能反
流式备份生成的是 .xbstream.zst 这类复合文件，还原要分两步走：先解压出原始 xbstream 流，再用 xbstream 解包进目标目录。跳过任意一步都会报 Invalid stream header 或 Failed to open stream。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 解压命令：
zstd -cd backup.xbstream.zst | xbstream -x -C /path/to/restore/ - 如果提示
xbstream: command not found，说明 Percona Toolkit 未安装（xbstream是percona-toolkit里的工具，不是xtrabackup自带） - 解包后目录里只有文件，没有
ibdata1或ib_logfile0？那是没加-x参数，或者源备份时漏了--extra-lsndir - 别忘了后续还要
xtrabackup --prepare，流式备份出来的数据仍是“未应用日志”的状态
MySQL 8.0 下 --lock-ddl-per-table 和 lock instance for backup 必须配对
MySQL 8.0 引入了数据字典（DD），物理备份时若不显式锁定 DD，可能在备份中途被 DDL 修改，导致 xtrabackup_binlog_info 与实际 binlog 位置错位。这不是警告，是真实会丢事务的硬伤。
- 备份命令中必须加
--lock-ddl-per-table（Percona XtraBackup 8.0.13+ 支持） - 对应 MySQL 端需提前执行
LOCK INSTANCE FOR BACKUP;（由xtrabackup自动触发，但前提是用户有BACKUP_ADMIN权限） - 检查权限是否到位：
SHOW GRANTS FOR 'xtrabackup'@'%';输出里必须含GRANT BACKUP_ADMIN ON *.* - 如果跳过这步，恢复后执行
SHOW MASTER STATUS可能显示空 binlog 文件名，主从搭建直接失败
流式压缩最易被忽略的其实是权限链：MySQL 用户要有 BACKUP_ADMIN，系统用户要有写入目标路径的权限，xbstream 工具得在 $PATH 里，而解压用的 zstd 或 lz4 得支持多线程——少一个环节，整个流水线就卡死在某条管道上。
