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
crontab 不是设了就完事常见现象：手动运行脚本成功，但 cron 执行后生成空文件或报 command not found —— 这几乎全是环境变量和路径惹的祸。
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
%date% 格式陷阱最多Windows 的 %date% 输出依赖系统区域设置，中文系统常是 2025/12/30 周二，直接截取 
%date:~0,10% 可能得 2025/12/3（少一位），导致目录名非法或覆盖失败。
Get-Date -Format "yyyyMMdd" 稳定且可控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 位点……任何一个环节松动，都可能让某次备份变成“看起来存在，实际无法还原”的假象。宁可多加一行日志、多测一次还原流程，也不要相信“上次能跑这次就一定行”。