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加密密钥没存进配置中心、解密命令敲错一个参数、或者备份前忘了关 binlog 导致日志暴涨——这些细节比算法选择更容易导致恢复失败。
