不能，直接拷贝 ibd 和 frm 文件无法安全使用，因依赖 ibdata1、事务日志、数据字典等完整组件，缺失任一将导致恢复失败。
直接拷贝 ibd 和 frm 文件能用吗？
不能，除非 MySQL 完全停止且没有写入——但即便如此，也极大概率恢复失败。因为 ibd 文件依赖 ibdata1（或独立表空间配置）、mysql.ibd、事务日志（ib_logfile0/1）、数据字典状态，甚至 buffer pool 中未刷盘的页。单独复制 ibd + frm，相当于只拿了半张拼图。
为什么 mysqldump 不算物理备份？
mysqldump 输出的是 SQL 文本，属于逻辑备份：它读取行、生成 INSERT 语句、不关心页结构或 redo log。恢复时要重新解析、执行、重建索引、重做 MVCC 信息——速度慢、锁表久、无法保证崩溃一致性。而物理备份要求字节级一致，能跳过 SQL 解析直接挂载启动。
真正安全的物理备份怎么做？
必须用官方或成熟工具在数据库运行时捕获一致性快照，核心是协调 InnoDB 的崩溃恢复机制：
- 使用
mysqlbackup（MySQL Enterprise Backup）或开源替代Percona XtraBackup——它们会：暂停 checkpoint、记录当前 LSN、拷贝所有数据文件 + 日志文件 + 系统表空间，并自动处理ibdata1与每个ibd的 LSN 对齐 - 若必须停机，需执行
SET GLOBAL innodb_fast_shutdown = 0后再service mysql stop，确保所有脏页刷盘、undo 清理完成，再整体拷贝/var/lib/mysql/下全部内容（不只是ibd/frm） - 注意
innodb_file_per_table=ON是前提，否则表数据全在ibdata1里，单拷ibd毫无意义 - 5.7+ 默认启用
innodb_undo_tablespaces，这些undo001等文件也得一起备份，漏掉会导致回滚段损坏
常见报错和误操作坑点
直接 cp ibd 后放回，启动时报错几乎全是这类：
-
Tablespace is missing for table 'db/tbl'：没拷frm或路径不对；但更可能是ibdata1里没对应表定义 -
InnoDB: Operating system error number 2 in a file operation：权限不对，或 SELinux/AppArmor 拦截了文件访问 -
Database page corruption on disk：拷贝时 MySQL 正在写，页被截断；或恢复时没用xtrabackup --apply-log做前滚 - 用
ALTER TABLE ... DISCARD TABLESPACE+IMPORT TABLESPACE试图“热替换”单表？必须严格满足：表结构完全一致、ROW_FORMAT和KEY_BLOCK_SIZE匹配、且ibd的 space id 与当前实例已分配的 id 冲突时会静默失败
物理备份最易被忽略的其实是日志文件和系统表空间的版本耦合性——MySQL 升级后，旧版 ibdata1 往往无法被新版直接读取，备份时得连 binlog 位置、server UUID、甚至 auto.cnf 都一并存档。
