За замовчуванням MySQL InnoDB зберігає всі таблиці всіх БД в одному глобальному файлі. Ви можете змінити це, встановивши в конфігурацію innodb_file_per_table, який потім створює один файл даних для кожної таблиці.

Мені цікаво, чому innodb_file_per_tableце не включено за замовчуванням. Чи є недоліки його використання?

Я маю повну відповідь на це.

Після того, як innodb_file_per_table буде встановлений, і нові таблиці InnoDB можна скоротити, використовуючи ALTER TABLE <innodb-table-name> ENGINE=InnoDB';Це зменшить нові .ibdфайли ГАРАНТИРОВАНО.

Якщо ви запускаєте ALTER TABLE <innodb-table-name> ENGINE=InnoDB';таблицю InnoDB, створену до того, як ви використовували innodb_file_per_table, вона витягне дані та індекси для цієї таблиці з файлу ibdata1 і збереже їх у .ibdфайлі. Це залишить постійний голуб у цілому ibdata1, який ніколи не можна використовувати повторно .

У ibdata1файлі зазвичай зберігається чотири типи інформації

• Дані таблиці
• Табличні покажчики
• Дані MVCC (мультивалюючий контроль за сумісністю)
  • Відхилення сегментів
  • Скасувати пробіл
• Метадані таблиці (Словник даних)
• Подвійний буфер запису (фоновий запис для запобігання надійності на кешування ОС)
• Вставити буфер (керування змінами не унікальних вторинних індексів)
• Дивіться Pictorial Representation of ibdata1

Ось гарантований спосіб зменшити файл ibdata1 майже назавжди ...

КРОК 01) MySQLDзавантажте всі бази даних у текстовий файл SQL (назвіть його SQLData.sql)

КРОК 02) Видалення всіх баз даних (крім схем mysql, information_schema та performance_schema)

КРОК 03) Вимкнення mysql

КРОК 04) Додайте наступні рядки до /etc/my.cnf

[mysqld]
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend

Сторінка: Незалежно від вашого набору для innodb_buffer_pool_size, переконайтесь, що innodb_log_file_size становить 25% від innodb_buffer_pool_size.

• КРОК 05) Видаліть ibdata1, ib_logfile0 та ib_logfile1 ( див. Оновлення нижче перед видаленням! )

На цьому етапі має бути лише схема mysql в / var / lib / mysql

• КРОК 06) Перезапустіть mysql

Це відтворить ibdata1 на 10 МБ (не налаштовуйте параметр), ib_logfile0 та ib_logfile1 на 1G кожен

• КРОК 07) Перезавантажте SQLData.sql в mysql

ibdata1 зростатиме, але містить лише метадані таблиці та переривчасті дані MVCC.

Кожна таблиця InnoDB існуватиме поза межами ibdata1

Припустимо, у вас є таблиця InnoDB під назвою mydb.mytable. Якщо увійти /var/lib/mysql/mydb, ви побачите два файли, що представляють таблицю

• mytable.frm (Заголовок двигуна зберігання)
• mytable.ibd(Дані даних таблиці та індекси таблиць для mydb.mytable)

ibdata1 більше ніколи не буде містити дані InnoDB та індекси.

За допомогою параметра innodb_file_per_table у /etc/my.cnf, ви можете запустити OPTIMIZE TABLE mydb.mytableАБО ALTER TABLE mydb.mytable ENGINE=InnoDB;і файл /var/lib/mysql/mydb/mytable.ibdфактично скоротиться.

Я робив це неодноразово у своїй кар’єрі як MySQL DBA, не так багато, як єдиної проблеми після цього. Насправді, коли я це зробив, я згорнув файл ibdata1 об'ємом 50 ГБ в 50 Мб.

Спробувати. Якщо у вас є додаткові запитання щодо цього, напишіть мені електронну пошту. Довірся мені. Це буде працювати в короткостроковій перспективі та в довгостроковій перспективі.

ОНОВЛЕННЯ 2013-07-02 15:08 EDT

У цьому відношенні є застереження, яке я оновлював у інших своїх посадах, але це пропустив: я трохи більше поновлював свою відповідь за допомогою innodb_fast_shutdown, оскільки для цього я перезапускав mysql і зупиняв mysql. Тепер цей крок є життєво важливим, оскільки кожна транзакція, що не відбулася, може мати інші рухомі частини всередині та поза журналами транзакцій InnoDB ( див. InnoDB Infrastructure ).

Зауважте, що встановлення innodb_fast_shutdown на 2 очистить журнали також, але більше рухомих частин все ще існує і потрапляє на Crash Recovery під час запуску mysqld. Установка 0 найкраща.

Дивіться про помилку .

Чи є недоліки його використання?

• більше відкритих файлів
• відкрити / знову відкрити накладні
• .ibd файл не скорочується (див. 1 , 2 )

Я завжди використовую innodb_file_per_table у великих базах даних.

innodb_file_per_table увімкнено за замовчуванням у MariaDB.

Причина, яку я вирішив не використовувати innodb_file_per_table, полягає в тому, що кожна таблиця розміщується у власному файлі, а це означає, що кожна таблиця отримує свій власний окремий накладний (підписи файлів тощо), що спричиняє загальний, загальний розмір MySQLкаталогу більше, ніж якщо ви використовуєте спільний простір таблиць. Крім того, є більше витраченого простору через кластер-слабкість при наявності декількох невеликих файлів замість одного, великого.

Зрозуміло, додаткові накладні витрати не є великою кількістю в грандіозній схемі речей, особливо якщо ви користуєтеся великим накопичувачем або маєте гігантську базу даних, але для себе (і, мабуть, багатьох «домашніх користувачів»), все це додалося і все ще було занадто багато для маленького диска з великими кластерами, де я зберігав свій магазин MySQL.

Наприклад, сховище моєї бази даних з моїми базами даних WordPress та кількома іншими невеликими базами даних (phpBB, dev, деякі тести AMP тощо), перетворення на таблицю змінило її з 32MB на 50MB, і це навіть не включає те, ibdata1що все ще вимагає більш мінімум 10MB , в цілому , по крайней мере 60MB.

Як я вже говорив, це може бути не надто великою проблемою для деяких людей, особливо підприємств, але якщо ви є домашнім користувачем, який розміщує лише ваш сайт, блог тощо, то це дійсно може бути фактором у таких речах, як вибір хост-провайдер, оскільки багато хостів обмежують розмір вашої бази даних на додаток до загального використання диска.

Просто, щоб додати трохи більше інформації

Оскільки mysql 5.6.6 його включено за замовчуванням

з innodb_file_per_table = 1, таблиця випадок може повільніше див. тут