У нас є додаток, де лише одна таблиця буде перетворюватися на мільйон рядків, а решта трохи нижче мільйона. Отже, яку пораду нам слід використати з innodb_file_per_table або залишити як один .ibd? Я читав деякі статті, говорять, що не йдіть з цим, оскільки вам потрібно більше доступу до диска, коли там потрібно приєднатися? Ми будемо приєднуватися між цією таблицею та іншими особами для цілей генерації звітів.
Відповіді:
Ви повинні перейти з innodb_file_per_table, і вам потрібно зробити деякі способи очищення з поточної інфраструктури InnoDB.
Я бачив багато клієнтів хостингу БД, які налаштовують MySQL і залишають InnoDB у своєму стані за замовчуванням. Це призводить до дикого зростання системного простору таблиць (більш відомого як ibdata1).
Навіть якщо ви перейшли на innodb_file_per_table, файл .ibd повинен бути вилучений з ibdata1, і ibdata ніколи не зменшиться. Наприклад, якщо у вас є таблиця з назвою mydb.mytable, яка знаходиться всередині ibdata1, займає 2 Гб, для її витягу вам доведеться:
КРОК 01) Додайте це до /etc/my.cnf
[mysqld]
innodb_file_per_tableКРОК 02) service mysql restart
КРОК 03) ALTER TABLE mydb.mytable ENGINE=InnoDB;
Це зробить файл /var/lib/mysql/mydb/mytable.ibd
На жаль, 2 Гб місця, яке було зайнято столом до зміни, неможливо повернути. Я писав минулі пости про те, як і чому очистити інфраструктуру InnoDB:
Після того, як ви зробите цю істотну зміну, не забудьте збільшити innodb_open_files (за замовчуванням 300) . В іншому випадку доступ до диска дуже обмежений.
Що стосується приєднань, переконайтеся, що у вас є відповідні індекси, які підтримують критерії приєднання.
Використання innodb_file_per_table у свіжій установці змушує ibdata1 рости дуже повільно, оскільки всі DDL виконуються зовні ibdata. Ви можете зменшити будь-яку таблицю InnoDB, як я вже згадував раніше:
ALTER TABLE mydb.mytable ENGINE=InnoDB;Що стосується резервного копіювання, будьте дуже обережні, роблячи копії файлів .ibd. Чому?
Всередині кожного .ibd-файла є спеціальне значення, відоме як tablepace_id. У ibdata1 є список значень tablepace_id. Якщо ви коли-небудь будете обслуговувати таблицю, яка потребує скидання та відтворення таблиці, tablepace_id стане іншим. Зробіть копію такого. Це ставить під загрозу tablepace_id всіх інших таблиць InnoDB. Зважаючи на це, бажано, щоб ви виконували резервні копії mysqldump, оскільки mysqldumps - це логічні копії даних. Іншими словами, резервна копія не залежить від моменту ibdata1, і ви можете перезавантажуватись без проблем з працездатністю.
Погодьтеся з @RolandoMySQLDBA, що він не згадує: резервне копіювання.
Якщо у вас все працює в режимі резервного копіювання MySQL, і ви не включаєте його .ibd-файл у стратегію резервного копіювання файлової системи, це не так важливо. Але врахуйте, що додавання ONE BYTES до будь-якої таблиці innodb призведе до додаткового резервного копіювання вашої.
У мене є додаток, де я маю саме таку ситуацію: кілька великих таблиць і кілька менших.
Я вирішив залишити малих на ibdata1час, поклавши більші у власні файли.
Я роблю це, будучи innodb_file_per_tableвключеним за замовчуванням , і тільки відключити його тимчасово для переміщення таблиці ibdata1з ALTER TABLE.
ALTER TABLEїх. Тож моя стратегія полягає в тому, щоб innodb_file_per_tableрегулярно вмикати та недбало вимикати її, щоб перемістити маленьку таблицю в ibdata1та після цього знову ввімкнути її.