У нас есть приложение, в котором только одна таблица будет расти в миллион строк, а остальные чуть меньше миллиона. Так какой совет мы должны использовать с 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 есть специальное значение, известное как tablespace_id. В ibdata1 есть список значений tablespace_id. Если вы когда-либо выполняете обслуживание таблицы, которое требует удаления и повторного создания таблицы, tablespace_id станет другим. Создание копии такого файла .ibd может быть добавлено обратно в базу данных только для использования, если вы также сделаете копию ibdata1. Это ставит под угрозу tablespace_id всех других таблиц InnoDB. В свете этого, желательно, чтобы вы выполняли резервные копии mysqldump, потому что mysqldumps являются логическими копиями данных. Другими словами, резервное копирование не зависит от момента времени ibdata1, и вы можете перезагрузить его без проблем с работоспособностью.
Согласитесь с @RolandoMySQLDBA за то, что он не упоминает: резервные копии.
Если у вас полностью отработан режим резервного копирования MySQL, и вы не включаете его файл .ibd в свою стратегию резервного копирования файловой системы, то это не так важно. Но учтите, что добавление ОДНЫХ БАЙТОВ в любую таблицу innodb приведет к инкрементному резервному копированию вашей таблицы .ibd, и вы увидите, что у вас быстро закончится резервное хранилище.
У меня есть приложение, где у меня именно такая ситуация: несколько больших таблиц и несколько меньших.
Я решил оставить маленькие в то ibdata1время как помещать большие в свои файлы.
Я делаю это, будучи innodb_file_per_tableвключенным по умолчанию , и только отключить его временно для перемещения таблицы ibdata1с ALTER TABLE.
ALTER TABLEих. Поэтому моя стратегия состоит в том, чтобы innodb_file_per_tableрегулярно включать и отключать его, чтобы переместить небольшой стол в ibdata1и затем снова включить его.