MySQL备份加密需用管道方式结合gpg或openssl，避免明文落地；恢复时应直接流式解密导入，禁用临时文件；应用层已加密字段无需双重加密，重点防范操作细节失误。
MySQL 备份时如何加密 mysqldump 输出
直接用 mysqldump 生成的 SQL 文件是明文，敏感字段（如 user.email、payment.card_number）裸露在外，不适用于生产备份。官方不提供内置加密选项，必须靠外部工具链实现加密。
最常用且可靠的方式是管道加密：在 mysqldump 输出后立即用 gpg 或 openssl 加密，避免中间文件落地。
- 使用
gpg（推荐，密钥管理更规范）：mysqldump -u root -p database_name | gpg --cipher-algo AES256 --compress-algo 2 --symmetric --armor > backup.sql.gpg
- 使用
openssl（轻量，但密码易被进程列表泄露）：mysqldump -u root -p database_name | openssl enc -aes-256-cbc -pbkdf2 -salt -out backup.sql.enc
- 务必加
--compress-algo 2（zlib）或-z参数压缩，否则加密后体积可能翻倍 - 不要用
mysqlpump替代 —— 它不支持输出到 stdout 的稳定格式，与加密管道兼容性差
恢复时解密并导入需绕过 shell 命令注入风险
解密后不能先写入临时文件再 source，否则存在竞态条件和磁盘残留；也不能用 $(cat ...) 或 eval 执行解密结果，极易触发 SQL 注入或 shell 注入。
安全做法是让 MySQL 客户端直接从标准输入读取解密流，全程内存处理：
-
gpg解密导入：gpg --decrypt backup.sql.gpg | mysql -u root -p database_name
-
openssl解密导入：openssl enc -d -aes-256-cbc -pbkdf2 -in backup.sql.enc | mysql -u root -p database_name
- 若遇到
ERROR 1044 (42000)权限拒绝，不是加密问题，而是目标库用户缺少FILE权限 —— 但这里根本没用LOAD DATA INFILE，所以实际是 MySQL 客户端版本与服务端协议不匹配，建议统一用 8.0+ 客户端
对已有明文备份补加密要避免二次解析失败
如果已生成了大体积 backup.sql，再用 gpg 加密看似简单，但要注意：该文件可能含 SET SQL_LOG_BIN=0、/*!40101 SET ... */ 等 MySQL 特有注释，而 gpg 对二进制安全，不会破坏内容；但若误用 iconv 转码或文本编辑器打开保存，会引入 BOM 或换行符损坏，导致恢复时报 ERROR 1064。
- 验证原始 SQL 是否可执行：
head -n 100 backup.sql | mysql -u root -p -D database_name --force --verbose 2>/dev/null || echo "syntax error detected"
- 补加密命令必须用二进制模式：
gpg --batch --yes --cipher-algo AES256 --compress-algo 2 --symmetric --armor backup.sql
- 加密后别名建议带时间戳和校验和：
backup_20240520.sql.gpg.sha256，便于后续验证完整性
应用层加密字段在备份中是否还需额外处理
如果业务已在应用层对敏感字段（如身份证号）用 AES_ENCRYPT() 存入数据库，那 mysqldump 导出的就是密文字符串 —— 这种情况下，再对整个 SQL 文件加密属于“双重加密”，不提升安全性，反而增加恢复复杂度和密钥管理负担。
- 判断依据：查表结构中字段类型是否为
VARBINARY或BLOB，且插入语句含AES_ENCRYPT(...)调用 - 此时只需对备份文件本身做传输/存储加密（即上文的
gpg），无需改动业务逻辑或加解密流程 - 但注意：MySQL 8.0+ 默认禁用
AES_ENCRYPT()，需显式开启block_encryption_mode='aes-256-cbc'，否则恢复时会报FUNCTION db.AES_DECRYPT does not exist
