MySQL 本身不提供“增量备份”命令，靠 binlog 实现
MySQL 没有
mysqldump --incremental这种原生命令。所谓“增量备份”，本质是开启并管理二进制日志（
binlog），把所有 DML/DDL 操作（除
SELECT）按时间顺序记下来。恢复时用
mysqlbinlog解析 +
mysql回放，就能还原某段时间的数据变化。
常见错误现象：
SHOW MASTER STATUS返回空、
log_bin变量为
OFF、
mysqlbinlog报错 “File not found”——基本都是没开
binlog或路径配置错误。 必须在
[mysqld]段落中添加
log-bin=/var/lib/mysql/mysql-bin（建议用绝对路径） 必须设置
server-id=1（主从或备份场景下不可为 0）
binlog_format推荐用
ROW：避免函数、触发器、非确定性语句导致主从/恢复不一致 重启 MySQL 后执行
SHOW VARIABLES LIKE 'log_bin';确认返回
ON
全量 + binlog 是生产级增量备份的最小可行组合
只靠
binlog无法从零恢复——它不包含初始结构和数据。所以真实备份策略永远是：一次全量 + 持续归档 binlog。
全量备份推荐用
mysqldump（逻辑）或
percona-xtrabackup（物理），取决于你的引擎和停机容忍度：
mysqldump -u backup -p --single-transaction --routines --triggers --databases db1 > full_$(date +%F).sql——适合中小库，需确保事务一致性
innobackupex --user=backup --password=xxx /backup/full/——适合大库、InnoDB 表多、不能锁表的场景 每次全备后立即执行
FLUSH LOGS，生成新 binlog 文件，方便后续按文件粒度归档 binlog 归档不能只靠保留文件：要用定时任务把
mysql-bin.0000xx复制到异地存储，并清空已归档的老日志（配合
PURGE BINARY LOGS）
恢复时最容易漏掉的关键点：position 和时间窗口
恢复不是简单回放所有 binlog。你得精准定位“从哪开始、到哪结束”。比如误删表后想恢复到删除前一秒，就必须知道两个坐标：
全备对应的binlog起始位置（来自全备时的
SHOW MASTER STATUS输出，或
xtrabackup_binlog_info文件） 误操作发生前的
binlog结束位置（用
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000002 | grep -A5 -B5 "DROP TABLE"定位） 若用时间恢复，务必确认服务器时区与 binlog 时间戳一致（
mysqlbinlog --start-datetime="2026-02-04 09:30:00"） 跳过某条语句？用
--stop-position或
--exclude-gtids（GTID 模式下更安全）
别把“差异备份”当“增量备份”用
有人用
mysqldump --where="updated_at > '2026-02-03'"生成“增量 SQL”，这其实只是条件导出，不是真正意义的增量备份： 它依赖业务字段（如
updated_at），一旦字段为空、被绕过或时钟不准，就漏数据 不记录 DDL（建表、改列）、用户权限变更、存储过程等元数据 无法做精确时间点恢复（PITR），也不能应对误执行
DROP DATABASE这类灾难 Percona XtraBackup 的
--incremental才是物理层增量：基于 InnoDB 数据页 LSN 差异，但必须接在全备之后，且只对 InnoDB 表有效
真正可靠的增量能力，始终建立在
binlog开启、归档可靠、全量基线清晰这三根柱子上。少一根，恢复就可能卡在半路。
