mysqldump是 MySQL 最常用、最轻量的备份类库，它不是第三方“类库”，而是官方自带的命令行工具——但正是因为它稳定、跨平台、无需额外安装，绝大多数自动备份方案都基于它构建。真正需要额外引入的“类库”（如 Python 的
mysql-connector-python或 Node.js 的
mysql2）通常只用于封装逻辑或集成进应用层，不直接承担备份文件生成职责。
用 mysqldump
写自动备份脚本，关键不是“选库”，而是参数和时机
很多人卡在“找不到好用的备份类库”，其实问题不在工具，而在对
mysqldump的理解偏差：它不是“不够用”，而是默认行为容易出错。
--single-transaction必加（InnoDB 表）：避免锁表，实现近似热备；不加可能导致备份过程中业务写入丢失或阻塞
--master-data=2建议加：记录 binlog 位置，为后续主从搭建或时间点恢复留依据
--set-gtid-purged=OFF要加（MySQL 5.7.6+）：否则导出 SQL 会包含
SET @@GLOBAL.GTID_PURGED，还原时可能报错
GTID_PURGED can only be set when GTID_EXECUTED is empty密码不要明文拼接在命令里（如
-p123），推荐用配置文件
~/.my.cnf避免泄露（尤其配合 cron 使用时）
#!/bin/bash
DB_NAME="myapp"
BKP_DIR="/backup/mysql"
DATE=$(date +%Y%m%d_%H%M)
<h1>推荐方式：通过 ~/.my.cnf 存凭证（权限 600）</h1><p>mysqldump --single-transaction --master-data=2 --set-gtid-purged=OFF \
--databases $DB_NAME | gzip > $BKP_DIR/${DB<em>NAME}</em>${DATE}.sql.gz</p>Linux 下定时执行，crontab
不是设了就完事
常见现象：手动运行脚本成功，但 cron 执行后生成空文件或报
command not found—— 这几乎全是环境变量和路径惹的祸。 cron 默认
PATH=/usr/bin:/bin，而
mysqldump常在
/usr/local/mysql/bin/或
/opt/mysql/bin/，必须写绝对路径或在脚本开头
export PATH=...脚本中用到的
date、
gzip等命令，也建议用绝对路径（
/bin/date、
/bin/gzip）或显式声明
PATH日志重定向别漏掉：
> /dev/null 2>&1会吞掉所有错误，应改为
> /var/log/mysql-bkp.log 2>&1方便排查
# 正确的 crontab 条目（每天凌晨 2:15 执行） 15 2 * * * /bin/bash /root/scripts/mysql-bkp.sh >> /var/log/mysql-bkp.log 2>&1
Windows 上用批处理自动备份，%date%
格式陷阱最多
Windows 的
%date%输出依赖系统区域设置，中文系统常是
2025/12/30 周二，直接截取
%date:~0,10%可能得
2025/12/3（少一位），导致目录名非法或覆盖失败。 更可靠的方式是用 PowerShell 替代 cmd：PowerShell 的
Get-Date -Format "yyyyMMdd"稳定且可控 如果坚持用 bat，先用
for /f解析
wmic os get localdatetime获取标准时间字符串
xcopy备份 data 目录虽快，但要求 MySQL 完全停止（
net stop mysql），生产环境慎用；
mysqldump是更安全的选择
@echo off
:: 推荐：调用 PowerShell 获取标准日期格式
for /f "delims=" %%i in ('powershell -Command "Get-Date -Format \"yyyyMMdd_HHmm\" "') do set DT=%%i
"D:\Program Files\MySQL\bin\mysqldump.exe" -uroot -pMyPass123 mydb > "F:\backup\mydb_%DT%.sql"
备份这件事，最难的从来不是“怎么写”，而是“怎么让每次执行都可预期”。路径、权限、时区、字符集、GTID、binlog 位点……任何一个环节松动，都可能让某次备份变成“看起来存在，实际无法还原”的假象。宁可多加一行日志、多测一次还原流程，也不要相信“上次能跑这次就一定行”。
