MySQL不停机在线备份关键在于选对工具与参数：InnoDB表可用mysqldump--single-transaction实现无锁热备（需REPEATABLE READ隔离级），而XtraBackup凭借物理级非阻塞备份、增量支持及高速恢复，成为50GB以上生产环境首选。
MySQL 实现不停机在线备份，关键不是“能不能”，而是“选对工具 + 用对参数”。InnoDB 表可以做到真正无锁热备；MyISAM 表只能温备（阻塞写入），无法零感知。生产环境若混用引擎，必须先确认表类型。
mysqldump --single-transaction 能否真正热备
能，但有前提：只对 InnoDB 表生效，且事务隔离级别需为 REPEATABLE READ（MySQL 默认）。它依赖 MVCC 快照，全程不加任何表级锁。
- 必须显式指定
--single-transaction，否则默认会触发--lock-all-tables（全局读锁） -
--master-data=2必须带上，否则备份文件里没有 binlog 位点，后续无法做主从或 PITR - 避免使用
--lock-tables或--add-locks，这两项会破坏热备能力 - 大库建议加
--quick和--max-allowed-packet=512M，防止内存溢出或导出中断
Percona XtraBackup 为什么是生产首选
因为它是物理级、非阻塞、支持增量的真正热备工具，尤其适合 50 GB 以上数据量。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 备份时对 InnoDB 数据文件执行
cp+redo日志应用，写入完全不受影响 - 不依赖 SQL 解析，恢复速度比
mysqldump快 3–10 倍（尤其大库） - 支持
--stream=tar直接压缩传输到远程，省本地磁盘空间 - 增量备份基于 LSN，
--incremental-basedir指向全量目录即可，无需解析 binlog - 注意：
XtraBackup 8.0+不兼容 MySQL 5.6，且对 MyISAM 表仍会自动加锁（应尽量避免）
GTID 环境下 mysqldump 容易踩的坑
开启 GTID 后，mysqldump 默认会写入 SET @@GLOBAL.gtid_purged，若目标实例已存在事务，恢复时直接报错 ERROR 1840 (HY000)。
- 跨实例迁移时，务必加
--set-gtid-purged=OFF - 如果要保留 GTID 信息用于主从，改用
--set-gtid-purged=AUTO，但需确保源库gtid_executed未被 purged -
SHOW MASTER STATUS和备份文件里的CHANGE MASTER TO位点可能不一致——GTID 模式下应优先用CHANGE MASTER TO MASTER_AUTO_POSITION = 1
备份后不做这三件事，等于没备
很多团队导完 backup.sql 就以为完成，其实真正风险在恢复链路上。
- 必须抽样验证：用
mysql -e "SELECT COUNT(*) FROM table_name"对比主从/备份前后行数 - 必须测试恢复流程：在测试机上跑一次
mysql 或 <code>xtrabackup --copy-back，卡在哪一步就暴露哪一步问题 - 必须归档 binlog：仅靠全量备份无法实现任意时间点恢复，
binlog_expire_logs_seconds至少设为 604800（7 天）
最常被忽略的是：备份文件权限和 SELinux 上下文。Linux 下若用普通用户运行 xtrabackup，恢复时 chown mysql:mysql 不彻底，MySQL 启动直接失败——这个错误不会出现在日志开头，而是在 error.log 中间某行带 Permission denied 的提示里。
