MySQL 8.0+ 官方命令行工具（mysqldump、mysqlpump）不支持--compress-output=LZ4，仅MySQL Shell 8.0.21+的util.dumpInstance()或管道结合外部lz4命令可实现LZ4压缩备份。
MySQL 8.0+ 直接用 mysqlpump 或 mysqldump 加 --compress-output=LZ4？别试了，不支持
MySQL 原生命令行工具（mysqldump、mysqlpump）至今（包括 8.0.33 及 8.4.0）**根本不识别 --compress-output=LZ4 这类参数**，强行加会报错 Unknown argument。官方只在企业版的 mysqlbackup 里支持 LZ4，社区版用户得绕道。
- 常见错误现象：
mysqldump: Unknown argument: --compress-output=LZ4 - 真正能用 LZ4 的入口只有两个：MySQL Shell 的
util.dumpInstance()/util.dumpSchemas()，或自己管道拼接外部压缩命令 - 注意版本门槛：MySQL Shell 8.0.21+ 才内置 LZ4 支持（需底层 liblz4 开发包已安装）
MySQL Shell 的 util.dumpInstance() 怎么开 LZ4 压缩
这是目前最接近“原生 LZ4 备份”的方案，压缩直接发生在导出过程中，避免中间文件和额外 I/O。
- 必须先确保 MySQL Shell 启动时能调用到 LZ4：Linux 上装
liblz4-dev（Debian/Ubuntu）或lz4-devel（RHEL/CentOS），再重装或重建 MySQL Shell - 连接后执行：
util.dumpInstance("/path/to/backup", {compression: "lz4", bytesPerChunk: "128M"}) -
compression: "lz4"是唯一有效值（不是"LZ4"或"lz4-fast"），大小写敏感 - 性能上，LZ4 比 gzip 快 3–5 倍，但压缩率低约 20%；适合磁盘 I/O 瓶颈明显、CPU 有余量的备份场景
用 mysqldump + lz4 管道压缩要注意什么
这是兼容性最强、控制最细的做法，但容易因缓冲区或信号处理翻车。
- 基础写法：
mysqldump --single-transaction --all-databases | lz4 > backup.sql.lz4
- 关键坑：
lz4默认用 stdin/stdout 流式压缩，但遇到 mysqldump 报错（如权限不足、锁表失败）时，lz4不会自动退出，导致备份文件看似生成实则为空或截断 - 务必加
set -o pipefail（bash）或用pipestatus检查各段退出码，例如：set -o pipefail; mysqldump ... | lz4 > backup.sql.lz4 || echo "dump failed"
- 如果备份大库，建议加
--max-allowed-packet=512M和--net-buffer-length=1M，避免 mysqldump 自身因网络缓冲溢出中断
还原时 lz4 解压和 mysql 导入怎么串才不丢数据
LZ4 解压本身很快，但还原环节最容易漏掉字符集或事务一致性控制。
- 不要用
lz4 -d backup.sql.lz4 | mysql这种裸管道：一旦 mysql 连接中断或权限报错，解压流还在继续，可能污染目标库 - 稳妥做法分两步：先解压校验完整性（
lz4 -t backup.sql.lz4），再导入：lz4 -d backup.sql.lz4 | mysql --default-character-set=utf8mb4
- 必须显式指定
--default-character-set，否则mysql客户端可能用 latin1 解析 utf8mb4 备份，导致乱码（尤其含 emoji 或四字节字符时） - 如果原备份用了
--single-transaction，还原时无需额外加事务控制——SQL 文件本身不含 BEGIN/COMMIT，逐条执行即可
