Архитектура InnoDB требует использования четырех основных типов информационных страниц
- Страницы табличных данных
- Таблицы указателей страниц
- Метаданные таблицы
- Данные MVCC (для поддержки изоляции транзакций и соответствия ACID )
- Откат сегментов
- Отменить пробел
- Double Write Buffer (фоновая запись для предотвращения зависимости от кэширования ОС)
- Вставить буфер (управление изменениями в неуникальных вторичных индексах)
См. Графическое представление ibdata1
По умолчанию innodb_file_per_table отключен. Это приводит к тому, что все четыре типа информационных страниц получают один файл с именем ibdata1. Многие люди пытаются распространить данные, создав несколько файлов ibdata. Это может привести к фрагментации данных и индексных страниц.
Вот почему я часто рекомендую очистить инфраструктуру InnoDB, используя файл ibdata1 по умолчанию и ничего более .
Копирование очень опасно из-за инфраструктуры, в которой работает InnoDB. Есть две основные инфраструктуры
- innodb_file_per_table отключен
- innodb_file_per_table включен
При отключенном innodb_file_per_table все эти типы информации InnoDB находятся в ibdata1. Единственным проявлением любой таблицы InnoDB за пределами ibdata1 является файл .frm таблицы InnoDB. Копирование всех данных InnoDB за один раз требует копирования всех файлов / var / lib / mysql.
Копирование отдельной таблицы InnoDB абсолютно невозможно. Необходимо извлечь дамп MySQL, чтобы извлечь дамп таблицы в виде логического представления данных и соответствующих им определений индекса. Затем вы должны загрузить этот дамп в другую базу данных на том же сервере или на другом сервере.
Если включен параметр innodb_file_per_table , данные таблицы и ее индексы находятся в папке базы данных рядом с файлом .frm. Например, для таблицы db1.mytable проявлением этой таблицы InnoDB вне ibdata1 будет:
/var/lib/mysql/db1/mytable.frm/var/lib/mysql/db1/mytable.ibd
Системное табличное пространство ibdata1
Все метаданные для db1.mytable по-прежнему хранятся в ibdata1, и это абсолютно невозможно . Журналы повторов и данные MVCC также все еще живут с ibdata1.
Когда дело доходит до фрагментации таблицы, вот что происходит с ibdata1:
- innodb_file_per_table включен : вы можете сжать db1.mytables с
ALTER TABLE db1.mytable ENGINE=InnoDB;илиOPTIMIZE TABLE db1.mytable;. Это приводит к тому, что /var/lib/mysql/db1/mytable.ibd физически меньше, без фрагментации.
- innodb_file_per_table отключен : вы не можете сжать db1.mytables с
ALTER TABLE db1.mytable ENGINE=InnoDB;илиOPTIMIZE TABLE db1.mytable;потому, что он находится с ibdata1. Фактически, запустив любую команду, вы сделаете таблицу смежной и быстрее будете читать и писать. К сожалению, это происходит в конце ibdata1. Это заставляет ibdata1 быстро расти. Об этом полностью говорится в моем сообщении по очистке InnoDB .
Если вы думаете просто о копировании файлов .frm и .ibd, вы стоите в очереди на мир причинения вреда. Копирование файлов .frm и .ibd таблицы InnoDB хорошо только тогда и только тогда, когда вы можете гарантировать, что идентификатор табличного пространства файла .ibd точно соответствует записи идентификатора табличного пространства в метаданных файла ibdata1 .
Я написал два сообщения в DBA StackExchange об этой концепции идентификатора табличного пространства
Вот отличная ссылка о том, как заново присоединить любой файл .ibd к ibdata1 в случае несовпадения идентификаторов табличного пространства: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . Прочитав это, вы должны сразу же понять, что копировать файлы .ibd просто безумие.
Для InnoDB, вам нужно только что-то это переместить
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
сделать копию таблицы InnoDB.
Если вы переносите его на другой сервер БД, используйте mysqldump.
Что касается смешивания всех таблиц InnoDB из всех баз данных, я действительно вижу мудрость в этом. В моей компании, занимающейся базой данных и веб-хостингом, у меня есть один клиент MySQL, у которого есть таблица в одной базе данных, ограничения которой сопоставлены с другой таблицей в другой базе данных в том же экземпляре MySQL. Благодаря единому хранилищу метаданных он обеспечивает поддержку транзакций и работоспособность MVCC в нескольких базах данных.