mysqldump本身不支持加密，必须通过管道结合openssl流式加密（如mysqldump db | openssl enc -aes-256-cbc -pbkdf2 -iter 1000000 -salt -md sha256 -out backup.enc），避免明文落盘风险；解密还原也须管道直连mysql，全程无临时明文文件。
直接用 mysqldump 或 mysqlpump 无法生成加密备份文件——它们输出的 SQL 始终是明文。真正可行的加密路径只有一条：导出数据时通过管道交给 openssl 或 gpg 实时加密，全程不落地明文。
为什么必须用管道流式加密，而不是先 dump 再加密
中间落盘的 backup.sql 文件哪怕只存在几秒，也可能被未授权进程读取、被勒索软件扫描锁定、或被运维误操作暴露在共享目录下。尤其在容器环境或云主机上，临时文件路径常被多个租户共享，风险更高。
- 错误做法：
mysqldump mydb > backup.sql && openssl enc -aes-256-cbc -in backup.sql -out backup.sql.enc - 正确做法：
mysqldump mydb | openssl enc -aes-256-cbc -pbkdf2 -iter 1000000 -salt -out backup.sql.enc - 如果数据库较大，建议加
gzip压缩：mysqldump mydb | gzip | openssl enc -aes-256-cbc -pbkdf2 -iter 1000000 -salt -out backup.sql.gz.enc
openssl 加密必须带哪些参数才安全
缺一不可。OpenSSL 默认行为（尤其是旧版本）安全性极弱，不显式指定就会用 MD5 摘要、无 salt、低迭代次数，等于没加密。
-
-pbkdf2：必须启用，否则使用过时的 EVP 密钥派生，易被暴力破解 -
-iter 1000000：迭代次数至少 10 万，MySQL 官方建议 ≥100000；低于 10000 基本无效 -
-salt：必须加，防止彩虹表攻击；漏掉会导致相同密码每次生成相同密钥 -
-md sha256：显式指定摘要算法；OpenSSL 1.1.1+ 默认是 sha256，但老版本默认 md5，跨环境解密必失败 - 避免
-pass pass:xxx：明文密码会留在ps aux和 shell history 中，应让 OpenSSL 交互式输入
解密失败报 bad decrypt 怎么快速定位
这不是文件损坏，而是加解密参数不一致。OpenSSL 不提示具体哪项错，只能靠排除法。
- 90% 是
-pbkdf2、-iter、-md三者中至少一项没对齐 - 检查命令是否完全复制粘贴：加密用了
-iter 1000000，解密就得写全-iter 1000000，不能省略 - 验证通路是否跑通：
openssl enc -d -aes-256-cbc -pbkdf2 -iter 1000000 -md sha256 -in backup.sql.enc 2>/dev/null | head -n 3—— 能输出前几行 SQL 才说明参数和密码都对 - 若输出为空或乱码，优先怀疑密码输错，其次再查参数
恢复时别解密到磁盘，直接喂给 mysql
解密后写成 tmp.sql 再导入，又制造了一个明文窗口。生产环境不允许任何中间明文文件存在。
- 正确还原命令：
openssl enc -d -aes-256-cbc -pbkdf2 -iter 1000000 -md sha256 -in backup.sql.enc | mysql -u root -p mydb - 如果用了 gzip 压缩：
openssl enc -d -aes-256-cbc -pbkdf2 -iter 1000000 -md sha256 -in backup.sql.gz.enc | gunzip | mysql -u root -p mydb - 注意：目标库字符集要和原库一致，否则中文变
?；可加--default-character-set=utf8mb4 - 大库导入前确认
max_allowed_packet足够，否则中途断开且无明确报错
最常被忽略的不是加密本身，而是验证——加密完立刻执行一次解密+导入测试。很多团队等到真实故障时才发现密钥记错、参数不匹配，或者压缩层嵌套导致解密后内容损坏。备份能还原，才算真正完成。
