MySQL 5.7原生不支持LSN增量备份，必须用XtraBackup；mysqldump是逻辑备份，不感知LSN，无法识别页级变更；mysqlbinlog基于binlog事件，粒度为事务/行，非数据页LSN，仅支持PITR而非物理增量。
MySQL 5.7 原生不支持基于 LSN 的增量备份 —— 必须用 xtrabackup（或已废弃的 innobackupex），mysqldump 和 mysqlbinlog 都不走 LSN 路线。
为什么 mysqldump 不行
mysqldump 是逻辑备份工具，它读取表数据并生成 SQL 语句，完全不感知 InnoDB 的 LSN。即使加了 --single-transaction，它也只是靠 MVCC 快照保证一致性，和数据页的物理修改时间无关。所以它无法判断“哪些页自上次备份后被改过”——这是 LSN 增量的核心前提。
- 执行
mysqldump时看不到任何 LSN 相关参数或输出 - 它无法跳过未修改的数据页，备份体积始终是全量级
- 恢复后需重放所有 SQL，不能跳过已存在的页
为什么 mysqlbinlog 也不算 LSN 增量
mysqlbinlog 解析的是二进制日志（binlog），记录的是 SQL 语句或行变更事件（取决于 binlog_format），不是数据页级别的物理变更。它的粒度是事务/语句/行，不是 InnoDB 数据页的 LSN。
-
binlog没有 LSN 字段，只有position和gtid - 它能做时间点恢复（PITR），但不是“只备份被修改过的页”，而是“备份所有变更事件”
- 如果只靠
binlog，你必须从上一个全备开始重放，中间任意 binlog 文件损坏就断链
真正基于 LSN 的增量：xtrabackup 工作流
xtrabackup（MySQL 5.7 推荐用 percona-xtrabackup-24）才是唯一利用 InnoDB LSN 实现物理增量的工具。它通过比对每个数据页头部的 LSN 与基准备份的 to_lsn，只拷贝 LSN 更大的页。
- 全量备份后，
xtrabackup在xtrabackup_checkpoints文件中记录to_lsn - 增量备份命令必须指定
--incremental-basedir=/path/to/full/，它会读该目录下的to_lsn作为起点 - 增量备份结果目录里也有自己的
xtrabackup_checkpoints，含新的to_lsn，供下一次增量使用 - 恢复时必须按顺序：全量 → 增量1 → 增量2 → … → 应用 redo log → 准备（
--apply-log）→ 恢复
示例关键命令：
xtrabackup --user=backup_user --password='xxx' --backup --target-dir=/backup/full/ xtrabackup --user=backup_user --password='xxx' --backup --incremental --incremental-basedir=/backup/full/ --target-dir=/backup/inc1/ xtrabackup --user=backup_user --password='xxx' --backup --incremental --incremental-basedir=/backup/inc1/ --target-dir=/backup/inc2/
容易被忽略的三个硬性前提
LSN 增量不是配好命令就能跑通，以下三点任一缺失都会导致备份失败或恢复不一致：
-
innodb_file_per_table=ON：必须启用，否则系统表空间（ibdata1）无法按页隔离，xtrabackup无法精确识别哪些页被修改 - 备份用户要有
REPLICATION CLIENT权限：用于获取当前LSN和binlog位置，缺它会在--backup阶段报错Failed to get LSN - 全量备份必须先
--prepare过（哪怕只是空跑）：否则其xtrabackup_checkpoints中的to_lsn可能为 0 或无效值，导致后续增量误判为“无变更”
LSN 增量的本质是页级物理快照链，不是日志流拼接——理解这点，才能避开把 binlog 当成 LSN 增量的常见误操作。
