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 步骤一个都不能少。