正确做法是用管道将 mysqldump 输出直连 SSH 隧道加密传输，避免本地落盘；需加 --single-transaction、-C、StrictHostKeyChecking=no，并通过 ~/.my.cnf 管理密码；SSH 隧道比 MySQL SSL 更简单可靠，且全程加密 TCP 流。
mysqldump 输出直接走 SSH 隧道，不落地明文
本地 mysqldump 产生的 SQL 流，不该先写到磁盘再 scp，那样既多一步 I/O，又暴露敏感数据。正确做法是用管道直连远程 SSH，让加密发生在传输层。
常见错误是把 mysqldump 和 ssh 当成两个独立命令拼凑，漏掉 -C（压缩）和 -o StrictHostKeyChecking=no（自动化场景下避免交互阻塞），或者忘了加 --single-transaction 导致备份不一致。
实操建议：
- 用
mysqldump --single-transaction -h localhost -u user -p'pass' db_name | ssh -C -o StrictHostKeyChecking=no user@host "cat > /backup/db_$(date +%Y%m%d).sql" - 如果远程磁盘空间紧张，可加
gzip：末尾改成ssh ... "gzip > /backup/db_$(date +%Y%m%d).sql.gz" - 别在命令行里写明文密码；改用
~/.my.cnf配置文件，并设权限chmod 600 ~/.my.cnf
MySQL 服务端没开 SSL？那 mysqldump 自己加不了 TLS
mysqldump 的 --ssl-mode=REQUIRED 只能加密「它连 MySQL 的那条连接」，对后续的 SSH 管道完全没影响。很多人以为加了这个参数就全程加密了，其实只是客户端到数据库这一跳加密，后面走 SSH 还是靠 SSH 自己的密钥协商。
所以：如果 MySQL 本身监听在内网且不暴露公网，--ssl-mode 不是必须的；但若 dump 命令要从不可信网络发起（比如跨云 VPC），那就得配好 MySQL 的 SSL 证书，并确认 require_secure_transport=ON 已生效。
注意点：
mysqldump --ssl-mode=REQUIRED --ssl-ca=/path/to/ca.pem --ssl-cert=/path/to/client-cert.pem --ssl-key=/path/to/client-key.pem- 检查 MySQL 服务端是否真启用了 SSL：
SHOW VARIABLES LIKE 'have_ssl';和SHOW STATUS LIKE 'Ssl_cipher'; - 证书路径必须是
mysqldump所在机器上的路径，不是 MySQL 服务器上的
SSH 隧道比 mysqldump 内建 SSL 更可靠也更简单
当目标只是“不让备份数据裸奔在线路上”，SSH 隧道比折腾 MySQL SSL 更省事：它不依赖 MySQL 版本、不用管证书过期、也不用配置 ssl_ca 等一堆变量。只要 SSH 能通，加密就成立。
性能上，SSH 的 AES-GCM 或 ChaCha20 加解密开销极小，现代 CPU 几乎无感；而 MySQL SSL 在高并发 dump 场景下可能因握手或证书验证拖慢速度。
关键差异：
- SSH 加密的是整个 TCP 流（含 shell 命令、文件名、SQL 内容），MySQL SSL 只加密协议包载荷
- SSH 支持密钥登录 + agent forwarding，适合脚本调度；MySQL SSL 依赖文件权限和路径硬编码
- 遇到
Write failed: Broken pipe或Connection reset by peer，优先查 SSH 连接稳定性，而不是怀疑mysqldump参数
备份大库时管道中断，怎么续传不重来
直接管道传几百 GB 的 dump，一旦 SSH 断开就得从头再来。这不是 mysqldump 的问题，而是缺少断点续传机制 —— 它输出是单向流，没法“跳过前 N 行”。
真正可行的方案不是修管道，而是换思路：用 mysqldump 分表导出，每张表单独走 SSH，失败只重试单表；或者改用 mysqlpump（MySQL 5.7+）配合 --default-character-set=utf8mb4 --compress 提升容错性。
轻量级补救法：
- 加
timeout 3600 ssh ...防止僵死连接卡住整个流程 - 用
rsync --partial --progress传已生成的压缩包，但它要求先落地文件，得权衡安全性 - 最稳的做法：在远程机器上跑
mysqldump，本地只拉结果 —— 虽然多一次远程执行，但规避了本地带宽和稳定性瓶颈
真正麻烦的从来不是加不加 SSL，而是备份过程中哪一环会静默失败：MySQL 连接超时、SSH 心跳断开、磁盘写满、甚至 date 命令在不同 locale 下格式错乱导致文件名冲突。这些细节比选哪种加密方式更值得盯紧。
