Answers:
对于MyISAM，复制非常简单，并且使用InnoDB完全具有100％的风险（接近自杀）。
从您的问题中，您长大了
cp /db1/mytable.frm /db2/mytable.frm
可以的。但是，您不能只移动.frm。您必须移动所有组件。从您的问题出发，我们来看一个名为db1.mytable的表。在正常安装中，该表位于/ var / lib / mysql / db1中。该表将构成三个文件。
您必须移动所有三个文件才能移动一个表。如果所有表都使用MyISAM存储引擎，则可以关闭mysql并复制掉。如果仅是复制表并将其放置在另一个数据库中，则应该使用SQL。
例如，如果要将db1.mytable复制到数据库db2，请执行以下操作：
CREATE TABLE db2.mytable LIKE db1.mytable;
ALTER TABLE db2.mytable DISABLE KEYS;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
ALTER TABLE db2.mytable ENABLE KEYS;
现在，如果只是将表从db1移动到db2，则可以执行以下操作：
ALTER TABLE db1.mytable RENAME db2.mytable;
由于InnoDB使用的基础架构，因此复制非常危险。有两种基本基础架构：1）禁用innodb_file_per_table和2）启用innodb_file_per_table
InnoDB的致命弱点是称为ibdata1的系统表空间文件（通常位于/ var / lib / mysql中）。该文件中包含什么？
禁用innodb_file_per_table后，所有这些类型的InnoDB信息都将存在于ibdata1中。ibdata1之外的任何InnoDB表的唯一表现是InnoDB表的.frm文件。一次复制所有InnoDB数据需要复制所有/ var / lib / mysql。
完全不可能复制单个InnoDB表。您必须mysqldump提取表的转储，作为数据及其对应的索引定义的逻辑表示。然后，您可以将该转储加载到同一服务器或另一台服务器上的另一个数据库中。
启用innodb_file_per_table后，表数据及其索引位于.frm文件旁边的数据库文件夹中。例如，对于表db1.mytable，该InnoDB表在ibdata1之外的表现为：
db1.mytable的所有元数据仍驻留在ibdata1中，绝对没有办法解决。重做日志和MVCC数据仍与ibdata1一起存在。
如果您只想复制.frm和.ibd文件，那么您很容易受到伤害。仅当您可以确保.ibd文件的表空间ID与ibdata1文件的metdata中的表空间ID条目完全匹配时，才复制InnoDB表的.frm和.ibd文件是好的。
我在DBA StackExchange中写了两篇有关此表空间ID概念的文章
这是有关在表空间ID不匹配的情况下如何将.ibd文件重新连接和ibdata1的绝佳链接：http : //www.chriscalender.com/ ? tag=innodb-error-tablespace-id-in-file 。读完这篇文章后，您应该就能明白我为什么要自杀了。
对于InnoDB，您只需要这样做
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
制作一个InnoDB表的副本。如果要将其迁移到另一个数据库服务器，请使用mysqldump。
.frm，.MYD和.MYI。
复制整个MySQL数据目录是一种实用的技术，假定MySQL服务已停止并且您要复制整个数据库服务器。
这是用于转移具有大索引的数据库的有用技术，并且mysql转储将不包含索引，而索引需要在导入时重新生成。我发现在设置MySQL从站时该技术很有用。
复制单个文件将取决于使用的表模式，但是在大多数情况下不是合适的解决方案。