MyISAM表可直接拷贝.frm/.MYD/.MYI三文件，因其无事务、无共享元数据依赖、无需日志对齐，结构天然自包含；而InnoDB因依赖ibdata1元数据和redo log，.ibd非真正独立，须配合FLUSH TABLES FOR EXPORT、.cfg文件及IMPORT TABLESPACE流程。
MyISAM 表能直接拷 .frm/.MYD/.MYI 文件，是因为它没有事务、没有共享元数据依赖、也不需要日志对齐。
MyISAM 文件结构天然“自包含”
MyISAM 的每张表由三个独立文件组成：.frm（表结构）、.MYD（数据）、.MYI（索引）。这三个文件之间不跨表引用，也不依赖任何全局文件（比如 ibdata1 或 ib_logfile*）。只要拷贝时表没被写入，数据页就是静态的、一致的。
常见错误现象：在业务高峰期直接 cp，结果 .MYD 和 .MYI 处于不同时间点，查出来索引指向空记录或乱码。
- 正确做法是先执行
FLUSH TABLES WITH READ LOCK（或停库），再拷贝三文件 - 目标库无需建表，放进去改属主（
chown mysql:mysql *.MY*）就能直接USE和SELECT - 字符集、排序规则等全靠
.frm自带，不依赖系统库或数据字典
InnoDB 为什么不能照搬？关键在 ibdata1 和 redo log
即使 innodb_file_per_table=ON，.ibd 文件仍不是真正自包含的——它的 space_id、索引根页位置、加密上下文等元数据都登记在共享表空间 ibdata1 中。目标库的 ibdata1 里没有这条记录，MySQL 启动就报 Tablespace is missing for table 'db/tbl'。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
更麻烦的是事务一致性：InnoDB 数据页随时被修改，且变更先记 ib_logfile*（redo log），再异步刷盘。直接拷 .ibd 得到的是“中间态”，可能含未提交事务的脏页，也可能缺已提交但还没刷进 .ibd 的更新。
- 漏掉
FLUSH TABLES FOR EXPORT→ 缺.cfg文件 →IMPORT TABLESPACE报Failed to open the tablespace file - 没同步
ib_logfile*→ 目标实例启动失败，或导入后数据异常 - 源/目标 MySQL 版本不一致（如 5.7 → 8.0）→
.frm已废弃，但.ibd内部页格式可能不兼容
跨实例迁移 MyISAM 表时仍需注意的细节
看起来简单，但实际操作中容易忽略几个硬性约束：
- 目标库必须关闭
skip_external_locking（默认开启），否则无法识别新拷入的文件 -
lower_case_table_names参数两端必须一致，否则.MYD文件名大小写不匹配导致表“存在但打不开” - 若源表用了
DATA DIRECTORY或INDEX DIRECTORY指向非默认路径，要一并拷对应目录，并在目标库用相同路径建表 - MyISAM 不支持外键，但若目标库有同名 InnoDB 表残留，
DROP TABLE可能误删，建议先SHOW CREATE TABLE确认引擎
真正能“直接拷就完事”的，只有 MyISAM 这种无状态、无日志、无共享元数据的存储引擎。InnoDB 的可靠性代价，就是物理迁移必须走配套流程——哪怕只是单表，.cfg 文件和 DISCARD/IMPORT 步骤一个都不能少。
