MySQL主流备份方式有四种：cp直拷贝、mysqldump、LVM快照、Percona XtraBackup；选择取决于数据量、停机容忍度、存储引擎（尤其是否全InnoDB）及binlog启用情况。
MySQL 主流备份方式就四种：cp 直拷贝、mysqldump、LVM 快照、Percona XtraBackup。选哪种，不看文档吹嘘，而要看你的数据量、停机容忍度、存储引擎（尤其是是否全用 InnoDB）、以及有没有启用 binlog。
用 mysqldump 备份：适合中小量、要跨版本/跨平台迁移的场景
它导出的是 SQL 文本，兼容性最强，但速度慢、锁表风险高（尤其没加 --single-transaction 时）。对 MyISAM 表默认会全局锁，InnoDB 表加了该参数才真正“热备”。
- 必须启用
binlog_format=ROW才能配合后续增量恢复；否则STATEMENT格式在某些函数或非确定性语句下可能回放失败 - 别用 root 用户直连备份——创建专用用户，只给
SELECT, LOCK TABLES, REPLICATION CLIENT, SHOW VIEW等最小权限 - 压缩和时间戳要一起上：
mysqldump -u backup -p'xxx' --single-transaction company_db | gzip > company_db_$(date +%Y%m%d_%H%M).sql.gz - 忽略日志库：
--ignore-table=mysql.general_log --ignore-table=mysql.slow_log，否则备份文件膨胀且无意义
用 Percona XtraBackup 备份：大库、要求真正热备、恢复快的刚需选择
它是目前唯一被广泛验证的 InnoDB 物理热备工具，支持流式备份、压缩、加密、增量备份，但只支持 InnoDB 和 XtraDB，MyISAM 表只能冷备（需加 --lock-ddl 或停写）。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 增量备份依赖全量备份的
xtrabackup_checkpoints文件，删掉全量就废掉所有后续增量，务必一起归档 - 恢复前必须执行
xtrabackup --prepare（合并日志），跳过这步直接启动 MySQL 会报错InnoDB: Database page corruption on disk - 备份时若遇到长事务，
xtrabackup会等它结束才开始拷贝，可能卡住；可通过--kill-long-transactions-timeout控制超时 - 不支持 MySQL 8.0+ 的角色（ROLE）权限导出，恢复后需手动重建角色授权
靠 binlog 做增量和 PITR：没有它，所有备份都只是“时间点快照”，不是真正的容灾能力
全量备份再快，也解决不了“误删一条记录”这种问题。binlog 是唯一能支撑精确到秒级恢复（Point-in-Time Recovery）的机制。
- 确认已开启：
SHOW VARIABLES LIKE 'log_bin';返回ON；若为OFF，改/etc/mysql/my.cnf加log_bin=/var/log/mysql/mysql-bin并重启 -
binlog_format必须是ROW，MIXED在某些场景下仍会退化为STATEMENT，导致闪回失败 - 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001查看内容，确认有你关心的 DML 操作；别等到恢复时才发现日志是空的或被自动清理了 -
expire_logs_days=7是底线，生产环境建议设为 14 或更久，并配合监控检查SHOW BINARY LOGS;是否连续
最容易被忽略的一点：备份不是“存下来就完事”，而是“能还原+能验证”。每周至少挑一个备份集，拉到测试机上跑一次 mysql -u root ，再查几条关键数据的 CRC32 或行数是否一致。很多团队直到真出事才发现备份文件损坏、字符集错位、或权限语句缺失——这些坑，只靠“备份成功”日志根本发现不了。
