主从复制不是备份，无法实现时间点恢复或数据兜底；它仅用于读扩展与高可用，存在延迟、不一致及不可逆等缺陷，而备份需可验证、可还原、离线独立，二者目标与机制根本不同。
主从复制不是备份，它不提供时间点恢复能力，也不能替代备份。 你删库了、误update全表了、主库磁盘炸了——这些场景下，仅靠从库几乎无法挽回。复制是“同步”，备份是“存档”，目标和机制完全不同。
主从复制：实时同步，但不可逆、有延迟、可能不一致
MySQL 主从复制本质是异步重放 binlog：主库写入 binlog，从库用 I/O thread 拉取并写入 relay log，再由 SQL thread 执行。它解决的是读扩展、高可用切换、负载分担，不是数据兜底。
- 延迟真实存在：网络抖动、大事务、从库性能差都会导致
Seconds_Behind_Master持续增长，甚至卡住 - 语句级复制（
STATEMENT）在NOW()、UUID()、用户变量等场景下必然产生主从不一致 - 行级复制（
ROW）虽更安全，但遇到全表 update 会生成海量日志，压垮磁盘 IO 和网络带宽 - 从库一旦开启写入（比如没设
read_only=ON），立刻脱离复制一致性，变成“脏副本”
备份：可回退、可验证、可离线，但需要主动管理
备份是把某时刻的数据状态固化下来，关键在于「可还原」和「可验证」。它不依赖主库持续运行，也不怕网络中断。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
mysqldump是逻辑备份，适合中小库迁移或结构导出，但恢复慢、锁表风险高（除非加--single-transaction） -
Percona XtraBackup是物理热备，支持增量、压缩、流式备份，恢复快，但只兼容 InnoDB/XtraDB，且版本必须严格匹配 MySQL 小版本（如 8.0.33 备份不能在 8.0.32 上恢复） - 二进制日志（
binlog）本身不是备份，但它是实现「时间点恢复（PITR）」的必要拼图：需配合最近一次全备 + 中间所有binlog文件才能还原到任意秒级时间点 - 不做校验的备份等于没做：
gunzip -t backup.sql.gz或xtrabackup --prepare后检查backup-my.cnf和xtrabackup_info是最低成本验证
常见混淆点：为什么“从库”不能当“备份库”用？
很多人把从库当成天然备份，这是最危险的认知偏差。从库和主库共享同一套逻辑缺陷：它执行的是同样的 SQL，受同样 bug 影响；它也受同样权限误操作波及；它的磁盘损坏概率并不比主库低。
- 从库没有独立的时间点快照，
FLUSH LOGS和SHOW MASTER STATUS在从库上查不到主库当时的位点 - 从库的
relay log默认不持久化到磁盘（sync_relay_log=10000），断电可能丢失未执行的中继日志 - 没有定期
mysqldump --all-databases --master-data=2或xtrabackup --slave-info记录复制位点，就无法建立“备份文件 ↔ 主库状态”的映射关系 - 真正可靠的备份策略 = 全量备份（每天）+ binlog 归档（每小时切割）+ 定期异地拷贝（如
rsync到另一台机器）
真正该花时间的地方，不是调参让复制延迟降到 0.1 秒，而是确保 backup_dir 里昨天的全备能通过 mysql -e "CHECK TABLE" 验证，且最近 3 小时的 binlog 文件都在、可解析、无截断。复制可以挂，备份不能假。
