Архітектура InnoDB вимагає використання чотирьох основних типів інформаційних сторінок
- Сторінки даних таблиці
- Сторінки покажчиків таблиць
- Метадані таблиці
- Дані MVCC (для підтримки ізоляції транзакцій та відповідності ACID )
- Відхилення сегментів
- Скасувати пробіл
- Подвійний буфер запису (фоновий запис для запобігання надійності на кешування ОС)
- Вставити буфер (керування змінами не унікальних вторинних індексів)
Дивіться зображальне зображення 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 Cleanup .
Якщо ви думаєте просто скопіювати файли .frm та .ibd, ви стоїте в черзі за все, що завдає шкоди. Копіювання файлів .frm та .ibd таблиці InnoDB добре лише тоді і лише тоді, коли ви можете гарантувати, що ідентифікатор простору таблиць .
Я написав два повідомлення в 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 з усіх баз даних, я можу насправді бачити мудрість у цьому. У компанії DB / Web-хостингу мого роботодавця у мене є один клієнт MySQL, який має таблицю в одній базі даних, обмеження яких відображаються в іншій таблиці в іншій базі даних в межах одного екземпляра MySQL. За допомогою одного загального сховища метаданих, це робить можливою підтримку транзакцій та оперативність MVCC в різних базах даних.