Копирование очень просто для MyISAM и полностью на 100% рискованно (почти самоубийственно) с InnoDB.

Из вашего вопроса вы подняли

cp /db1/mytable.frm /db2/mytable.frm

MyISAM

Это нормально. . Однако нельзя просто переместить .frm. Вы должны переместить все компоненты. Из вашего вопроса возьмем таблицу с именем db1.mytable. При обычной установке таблица находится в / var / lib / mysql / db1. Таблица будет состоять из трех файлов.

• /var/lib/mysql/db1/mytable.frm
• /var/lib/mysql/db1/mytable.MYD (База данных таблиц)
• / var / lib / mysql / db1 / mytable.MYI (индексы таблиц)

Вы должны переместить все три файла, чтобы переместить одну таблицу. Если все ваши таблицы используют механизм хранения 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

Копирование очень опасно из-за инфраструктуры что InnoDB работает под. Есть две основные инфраструктуры: 1) innodb_file_per_table отключен и 2) innodb_file_per_table включен

Ахиллесова пята InnoDB - это системный файл табличного пространства, известный как ibdata1 (обычно находится в / var / lib / mysql). Что содержится в этом файле ?

• Страницы данных таблиц
• Страницы индексов таблиц
• Метаданные таблицы (список управления идентификаторами табличных пространств)
• MVCC Данные (для поддержки изоляции транзакций и Соответствие ACID )

InnoDB (innodb_file_per_table отключен)

Если innodb_file_per_table отключен, все эти типы информации InnoDB хранятся в ibdata1. Единственное проявление любой таблицы InnoDB вне ibdata1 - это файл .frm таблицы InnoDB. Для одновременного копирования всех данных InnoDB необходимо скопировать все /var/lib/mysql.

Копирование отдельной таблицы InnoDB совершенно невозможно. Вы должны использовать mysqldump для извлечения дампа таблицы как логического представления данных и соответствующих определений индекса. Затем вы должны загрузить этот дамп в другую базу данных на том же сервере или другом сервере.

InnoDB (innodb_file_per_table enabled)

При включенном innodb_file_per_table данные таблицы и ее индексы находятся в папке базы данных рядом с файлом .frm. Например, для таблицы db1.mytable проявление этой таблицы InnoDB вне ibdata1 будет:

• /var/lib/mysql/db1/mytable.frm
• / var / lib / mysql / db1 / mytable .ibd

Все метаданные для db1. mytable по-прежнему находится в ibdata1 и , нет никакого способа обойти это . Журналы повторного выполнения и данные MVCC также все еще хранятся в ibdata1.

ПРЕДУПРЕЖДЕНИЕ (или ОПАСНОСТЬ, как робот сказал бы в Затерянных в космосе )

Если вы думаете просто скопировать .frm и .ibd файл, вы в очереди за миром боли. Копирование файлов .frm и .ibd таблицы InnoDB полезно только в том случае, если вы можете гарантировать, что идентификатор табличного пространства файла .ibd точно совпадает с записью идентификатора табличного пространства в метданных файла ibdata1.

Я написал два сообщения в DBA StackExchange об этой концепции идентификатора табличного пространства

• https://dba.stackexchange.com/a/9555/877 (под заголовком «Восстановление баз данных»)
• https://dba.stackexchange.com / a / 6269/877

Вот отличная ссылка на то, как повторно подключать и. 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.