mysqldump 单独无法实现增量备份，必须依赖 binlog 与 mysqlbinlog 配合；Windows 下需任务计划+批处理，但须确保 server-id、binlog_format 合规，全备加 --flush-logs 和 --master-data=2，增量则提取对应 binlog 位置后的日志。
mysqldump 能做定时全量备份，但单独用它无法真正实现增量备份——真正的增量依赖 binlog，且必须配合 mysqlbinlog 工具和明确的起止位置。Windows 下没有 cron，靠任务计划程序 + 批处理脚本是可行路径，但每一步都有权限、路径、时序陷阱。
确认 binlog 已启用且配置合规
增量备份的前提不是“开了 log_bin”，而是：server-id 必填、binlog_format 合理、日志能被外部工具读取。常见错误是配置后没重启服务，或 show variables like 'log_bin' 返回 OFF。
-
log_bin必须设为绝对路径（如C:/MySQL/Data/mysql-bin），避免默认写入 data 目录导致权限拒绝 -
server-id=1不可省略，哪怕单机；值必须是整数，不能是 0 或空 -
binlog_format=ROW比 STATEMENT 更安全，尤其含 NOW()、UUID() 等函数时不会丢数据 - 改完
my.ini后，用services.msc重启 MySQL 服务，再进 MySQL 执行SHOW VARIABLES LIKE 'log_bin%';验证
全量备份脚本要带 --flush-logs 和 --master-data=2
只用 mysqldump -u root -p db > backup.sql 是危险的：它不记录 binlog 位置，后续增量无法衔接。必须加关键参数锁定快照起点。
windows-shell-syntax
下载
在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……
-
--single-transaction：对 InnoDB 表无锁，但 MyISAM 仍会锁表，慎用 -
--flush-logs：强制生成新 binlog 文件，让后续增量从干净起点开始 -
--master-data=2：在 dump 文件开头插入CHANGE MASTER TO注释，含当前 binlog 文件名和偏移量 -
--routines --events --triggers：否则存储过程、事件、触发器不会被导出 - 示例命令：
mysqldump --single-transaction --flush-logs --master-data=2 -u root -p db_blbl > D:\backup\full_%date:~0,4%%date:~5,2%%date:~8,2%.sql
增量备份本质是拷贝新 binlog 文件，不是再跑 mysqldump
很多人误以为“增量备份 = 再 dump 一次”，其实那是全量。真正的增量就是把自上次全备以来新增的 mysql-bin.0000xx 文件复制出来，并确保它们未被 expire_logs_days 清掉。
- 先查上次全备时的 binlog 位置：打开全量 SQL 文件，找类似
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=1234;的行 - 用
mysqlbinlog提取该位置之后的操作：mysqlbinlog --start-position=1234 C:\MySQL\Data\mysql-bin.000003 > D:\backup\incremental_000003.sql - 若跨多个文件（如 000003 → 000004），需按顺序拼接，且
--stop-datetime比--stop-position更易控时间点 - 注意：
mysqlbinlog默认输出带 SET @@SESSION.GTID_NEXT，恢复前可能需加--skip-gtids参数
任务计划程序里执行 bat 脚本的三个硬性条件
Windows 任务计划默认以非交互式账户运行，脚本失败往往不是逻辑错，而是环境缺失。
- 脚本第一行加
@echo off & cd /d "C:\MySQL\bin"：确保mysqldump.exe和mysqlbinlog.exe在当前目录可执行 - 密码不能明文写在命令里（
-p123456），应改用配置文件：my.cnf放在脚本同目录，内容为[client]\nuser=root\npassword=123456，再加--defaults-file=my.cnf - “运行方式”必须勾选“不管用户是否登录都要运行”+“使用最高权限运行”，否则访问 data 目录会报“拒绝访问”
- 测试时右键任务→“运行”，看“历史记录”里有没有 0x1 错误码——有则大概率是权限或路径问题
全量与增量之间的时间锚点（binlog 文件名 + position）极易断链，一旦全量脚本没带 --flush-logs 或增量提取时跳过了中间文件，整个恢复链就失效了。不要依赖“看起来备份成功了”，每次全备后手动检查 dump 文件头部是否有 MASTER_LOG_FILE 行，才是真保险。
