应使用 mysqldump -u root -p database_name > backup_$(date +\%Y\%m\%d_\%H\%M\%S).sql 生成带秒级时间戳的独立备份文件，避免同天覆盖、兼容 cron、防止解析错误，并确保备份与 binlog 恢复链完整。
如何用 mysqldump 生成带时间戳的独立备份文件
直接覆盖旧备份等于没备份，必须让每次备份可区分、可追溯。mysqldump 本身不管理文件名，得靠 shell 拼接时间戳。常见错误是用 date +%Y-%m-%d 导致同天多次备份被覆盖——应精确到秒。
- 推荐命令：
mysqldump -u root -p database_name > backup_$(date +\%Y\%m\%d_\%H\%M\%S).sql - 避免空格或冒号（
:）出现在文件名里，Linux 下部分工具会误解析；用下划线+纯数字最稳妥 - 如果脚本中调用，记得给
date命令加反斜杠转义百分号，否则 cron 里执行会失败 - 别把备份写到 MySQL 数据目录下（如
/var/lib/mysql），万一磁盘满或权限错，可能影响主库运行
为什么不能只靠 mysqlbinlog 做全量恢复链
mysqlbinlog 只能回放增量日志，但它的起点必须是一个有效的全量备份快照。没有这个锚点，binlog 就是一串无法定位起始状态的事务流。
- 全量备份（
mysqldump或Percona XtraBackup）是恢复链的“基线”，必须定期做，且要记录对应SHOW MASTER STATUS的File和Position - binlog 开启前提：MySQL 配置里
log-bin必须启用，且expire_logs_days别设太小，否则旧 binlog 被自动清理，断掉恢复链 - 常见坑：用
--single-transaction备份时，若库中有非 InnoDB 表（如 MyISAM），mysqldump不保证一致性，后续用 binlog 追平会出数据偏差
用 find + mtime 自动清理过期备份的安全边界
备份占空间，但删错了会导致无法恢复。单纯按天数删（如 find /backups -name "*.sql" -mtime +7 -delete）风险高——它不识别备份是否已被纳入当前恢复链。
- 优先按“保留最近 N 个完整备份”策略删，而不是“删 7 天前所有文件”；可用
ls -t backup_*.sql | tail -n +6 | xargs rm保留最新 5 个 -
-mtime +7是“修改时间大于 7×24 小时”，不是“超过 7 天”，跨夏令时或系统时间跳变时结果不可控 - 删除前务必确认目标路径无通配符误扩（比如
/backups/*.sql写成/backups/*），建议先用echo预览再真删 - binlog 文件也要同步清理，但得比最老全量备份多留至少 1 天，防止恢复时日志缺失
mysqldump 备份时要不要加 --master-data=2
要，但得清楚它干了什么：在 dump 文件开头插入 CHANGE MASTER TO 语句，并附上备份时刻的 binlog 位置。这是构建主从或 PITR（基于时间点恢复）的关键元数据。
- 值为
1时语句不注释，直接执行会尝试建从库；2时语句被注释，更安全，恢复后手动解注释即可 - 仅对开启了
log-bin的实例有效；如果备份的是从库，且想保留其复制关系，需额外加--dump-slave=2 - 加了这个参数，
mysqldump会自动加FLUSH TABLES WITH READ LOCK（除非用了--single-transaction），锁表时间取决于数据量，大库慎用 - 注意：该参数不保存 binlog 文件内容，只记位置；恢复时仍需确保对应 binlog 文件未被清理
SHOW MASTER STATUS 输出、binlog 截止位置有没有手误抄错、清理脚本有没有漏掉某类文件后缀。这些细节不写进自动化流程，光靠人脑记，迟早出问题。 
