MySQL 主从复制备份方式对比
一句话结论：InnoDB 有事务、有共享表空间、有内存/日志状态，在线直接拷文件会碎；MyISAM 无事务、文件独立，锁表后直接拷很安全。
一、InnoDB 为什么推荐 mysqldump（逻辑备份）
1. InnoDB 是事务型引擎，有强一致性要求
- 运行中存在未提交事务、undo、redo log、buffer pool 脏页
- 直接拷数据文件（.ibd、ibdata1）会把中间状态、未提交数据、半完成事务一起拷走
- 结果：从库启动后数据不一致、页损坏、丢数据
2. InnoDB 表空间高度耦合
- 默认共享表空间
ibdata1：存全局数据字典、事务信息、undo、索引根页 - 即使
innodb_file_per_table=ON，.ibd 里只有数据和二级索引，元数据、事务ID、LSN 仍在 ibdata1 - 只拷某个库的 .ibd ≈ 只拷了”数据页”，没有字典和事务上下文
3. mysqldump + —single-transaction 能拿到一致性快照
- InnoDB 用 MVCC，开一个事务，整个备份期间读的是同一时间点的数据
- 不锁表、不停库，在线就能导出一致数据
- 导出的是 SQL，跨版本、跨平台、校验简单
4. 主从复制需要准确的 binlog 位点
- mysqldump 加
--master-data，会自动记录 binlog 位点 - 直接拷文件很难精准对应 binlog 位点
二、MyISAM 为什么可以直接复制数据文件
1. MyISAM 非事务引擎
- 没有 redo/undo，写操作直接落盘，没有”中间态”
- 只要锁表（FTWRL）或停库，数据文件就是静止、一致的
2. MyISAM 文件完全独立
每个表 3 个文件：
.frm：表结构.MYD：数据.MYI：索引
不依赖共享表空间，单表可独立拷贝。
3. 拷贝快、恢复快
物理复制比 mysqldump（走 SQL 解析+重放）快几倍到几十倍，适合大数据量、停机窗口短的场景。
三、核心对比
| 特性 | InnoDB | MyISAM |
|---|---|---|
| 事务 | ✅ 有（ACID） | ❌ 无 |
| 数据文件依赖 | 强（ibdata1 + .ibd + 日志） | 弱（单表独立文件） |
| 在线直接拷文件 | ❌ 危险（不一致、损坏） | ✅ 安全（锁表后） |
| 推荐初始化方式 | mysqldump --single-transaction | 物理拷贝（cp/rsync） |
| 一致性保证 | MVCC 快照 | 锁表/停库 |
四、InnoDB 非要物理拷贝怎么办？
必须严格满足：
- 正常慢停 MySQL（不是 kill -9），确保 redo 都刷盘
- 拷贝整个 datadir：ibdata1、所有 .ibd、ib_logfile*、auto.cnf 等
- 主从版本、页大小、字符集、innodb_file_per_table 完全一致
- 启动从库前重置 server-uuid，避免主从 UUID 冲突
五、主从搭建标准做法（2026）
InnoDB（默认）
mysqldump -u root -p --single-transaction --master-data=2 --all-databases > all.sql从库导入后直接 CHANGE MASTER。
MyISAM（老库）
FLUSH TABLES WITH READ LOCK;拷贝 datadir，从库改 server-uuid，启动后 CHANGE MASTER。
关联文档
- MySQL 高可用方案 — 高可用架构方案
- MySQL binlog 保留时间与清理 — binlog 配置实操
- ../../kubernetes/core/K8s 核心概念#StatefulSet — MySQL 有状态部署