mysqldump是MySQL官方自带的轻量级命令行备份工具，非第三方类库；关键在于正确使用–single-transaction、–master-data=2、–set-gtid-purged=OFF等参数，并通过~/.my.cnf管理密码、绝对路径调用命令、规范日志与定时任务配置。

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) 
推荐方式：通过 ~/.my.cnf 存凭证（权限 600）
mysqldump --single-transaction --master-data=2 --set-gtid-purged=OFF  --databases $DB_NAME | gzip > $BKP_DIR/${DBNAME}${DATE}.sql.gz

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 FilesMySQLbinmysqldump.exe" -uroot -pMyPass123 mydb > "F:backupmydb_%DT%.sql"

备份这件事，最难的从来不是“怎么写”，而是“怎么让每次执行都可预期”。路径、权限、时区、字符集、GTID、binlog 位点……任何一个环节松动，都可能让某次备份变成“看起来存在，实际无法还原”的假象。宁可多加一行日志、多测一次还原流程，也不要相信“上次能跑这次就一定行”。