必须用--apply-log-only合并增量，否则全量备份被激活导致后续增量无法叠加；因不加该参数会使xtrabackup将redolog完全应用并清零to_lsn，破坏LSN链条，使恢复链断裂。
准备阶段必须用 --apply-log-only 合并增量，否则全量备份会被“激活”而无法再叠加后续增量。
为什么 --apply-log-only 不可省略
全量备份准备时若不加 --apply-log-only，xtrabackup --prepare 会把重做日志（redolog）完全应用，并将备份标记为“可启动状态”，此时 to_lsn 被清零或冻结，后续增量无法再基于它合并——直接导致恢复链断裂。
增量合并的本质是“把变化追加到全量的末尾”，不是“让全量立刻能跑”。所以每一步合并都得保持全量备份仍处于“待叠加”状态。
- 全量首次准备：
xtrabackup --prepare --apply-log-only --target-dir=/backup/full - 第一次增量合并：
xtrabackup --prepare --apply-log-only --target-dir=/backup/full --incremental-dir=/backup/inc01 - 最后一次增量合并（如 inc02）：
xtrabackup --prepare --target-dir=/backup/full --incremental-dir=/backup/inc02（这步才去掉--apply-log-only）
xtrabackup_checkpoints 是判断是否可继续叠加的关键依据
每次执行 --prepare 后，检查 /backup/full/xtrabackup_checkpoints 文件内容：
- 含
backup_type = full-prepared→ 已被激活，不能再加增量 - 含
backup_type = incremental且to_lsn持续增长 → 表明增量已成功合并、链条完整 - 若
to_lsn停滞或倒退 → 增量路径指定错误，或--incremental-dir指向了非对应备份集
别只看命令有没有报错，一定要翻这个文件确认 LSN 是否递进。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
常见错误：误用 --use-memory 导致 --apply-log-only 失效
--use-memory 只影响日志回放速度，和是否“仅应用日志”无关。但它若设得太小（如 --use-memory=100M），可能使日志应用中断而不报错，结果 xtrabackup_checkpoints 状态异常，表面成功实则损坏。
- 建议值：物理内存的 50%～75%，但不低于 2G（
--use-memory=2G是较安全的下限） - 增量合并时，
--use-memory应与全量准备时一致，避免因缓存策略差异引发校验失败 - 如果合并后
ibdata1大小没明显增长，大概率是--use-memory不足导致跳过部分日志
最后一步不加 --apply-log-only 才真正收尾
只有当所有增量都合并完毕，才执行最终准备：
xtrabackup --prepare --target-dir=/backup/full
这时 xtrabackup_checkpoints 中的 backup_type 会变成 full-prepared，to_lsn 固定为最终值，备份集才可用于 --copy-back。此前任何一次漏掉 --apply-log-only，都会让这一步失败或恢复出错数据。
LSN 链条是隐式依赖，看不见摸不着，但一断就全盘失效——最易被忽略的，就是中间某次合并忘了加那个 --apply-log-only。
