MySQL无原生增量备份，XtraBackup基于LSN实现真正物理增量；mysqldump--where仅为条件导出，非一致性备份；性能关键在binlog与I/O配置优化。
增量备份本身不提高性能，它降低的是备份开销
MySQL 没有原生的“增量备份”功能（不像 PostgreSQL 的 pg_basebackup + WAL 归档那样直接支持）。所谓 MySQL 增量备份，本质是基于 mysqldump 的条件导出、或依赖 mysqlbinlog 解析二进制日志，或借助 Percona XtraBackup 的增量备份能力。它不会让查询变快、也不会加速写入——它的价值在于：减少每次备份的数据量、缩短备份窗口、节省存储和网络带宽。
用 xtrabackup --incremental 才算真正意义上的增量备份
Percona XtraBackup 是目前 MySQL 生态中唯一成熟支持物理级增量备份的工具。它基于 InnoDB 的数据页 LSN（Log Sequence Number）差异来识别变化页。
实操要点：
- 必须先完成一次全量备份：
xtrabackup --backup --target-dir=/backup/full - 后续增量基于该全量的 LSN：
xtrabackup --backup --incremental --incremental-basedir=/backup/full --target-dir=/backup/inc1 - 恢复时必须按顺序合并：
xtrabackup --prepare --apply-log-only --target-dir=/backup/full，再--incremental-dir=/backup/inc1，最后对 full 再执行一次--prepare（不加--apply-log-only） - 注意：增量备份不能跳级合并（比如全量 → inc2，跳过 inc1），LSN 链必须连续
mysqldump 加 --where 不是增量备份，只是条件导出
常见误解：用 mysqldump --where="updated_at > '2024-01-01' 导出“新数据”。这既不保证一致性（无事务快照），也不包含 DDL 变更，更无法用于恢复整库。它只适合特定场景下的数据同步或归档，不能替代备份。
风险点：
- 表结构变更（如新增列）会导致 dump 失败或数据错位
- 没锁表时，
--where条件可能漏掉正在更新的行（MVCC 可见性问题） - 无法还原到某个时间点，因为缺失 binlog 位置信息
真正影响备份性能的关键其实是 binlog 和 I/O 配置
即使用了 XtraBackup 增量，如果 MySQL 本身配置不合理，备份过程仍会卡顿或拖慢业务：
- 确保
innodb_log_file_size足够大（至少 1GB），避免备份期间频繁 checkpoint - 关闭
innodb_flush_log_at_trx_commit=2（仅限从库或可容忍少量数据丢失的场景）能显著降低刷盘压力 -
sync_binlog=0或sync_binlog=1000可缓解 binlog 写入瓶颈（但会影响主从延迟和崩溃恢复精度） - XtraBackup 默认启用
--parallel=4和--compress，但压缩会吃 CPU；SSD 上建议关压缩、开并行；HDD 上可适度压缩但降低并行数
增量备份不是银弹。LSN 合并逻辑、备份链管理、定期全量轮转（比如每周一全量+每日增量）、以及真实恢复演练——这些环节出错，备份就等于没做。
