Конечно, использование innodb_file_per_table является стандартной рекомендуемой конфигурацией, и, естественно, он может только обеспечить максимальную пользу, если эта функция включено перед тем генерируемых массивный системный файл табличного, ibdata1.
Предполагая, что вы все это сделали правильно, если вы все еще видите, что оно значительно растет, вы делаете что-то, чтобы заставить его расти.
См https://www.percona.com/blog/2013/08/20/why-is-the-ibdata1-file-continuously-growing-in-mysql/
журнальном (!), Словарь данных, и кухонная раковина все еще хранится там, так что это не так, если MySQL (InnoDB) просто выделяя все больше и больше места на диске и то просто забывайте об этом, а затем просите больше. Ваша рабочая нагрузка во многом определяет этот рост.
XtraDB является InnoDB с точки зрения структур данных диска. Возьмите сервер MySQL, остановите его, извлеките двоичные файлы MariaDB или Percona Server и запустите их ... и XtraDB использует ваши файлы ibdata1 и log и .ibd как босс, как и они. Предположительно, это идет и по-другому, но никто никогда не пробовал. (Шутка. Но серьезно, в моей сети из десятков серверов MySQL-esque, я никогда не переносил машину на MariaDB или Percona Server, а позже подумал: «Вау, я бы хотел, чтобы я вернулся к версии MySQL Oracle». Часть о XtraDB, использующая существующие файлы ibdata1 и .ibd, не шутка, это все правда. Я даже взял необработанные двоичные файлы данных из MySQL в Solaris и скопировал их на Linux-машину и начал с ними работу MariaDB - нет проблем.)
Представьте это с той же нагрузкой, и вы должны ожидать подобного роста ... хотя и не обязательно одинакового роста. Но XtraDB не является InnoDB в том, как он выполняет те же действия с теми же файлами, что и InnoDB. Это умнее и быстрее во многих отношениях, и в ограниченной степени может быть сконфигурировано для ограничения его роста, но это не будет работать с экстремальной магией на ваших дисковых пространствах, потому что для этого потребуется одно и то же пространство для выполнения той же работы. По существу, в смысле присутствия на диске, это все еще InnoDB.
Здесь хранятся данные в ваших таблицах. Даже с file_per_table он хранит метаданные, буферы и журналы. Почему это проблема"? – Devon
Я с @Devon по этому вопросу. Почему вы обеспокоены тем, что делает InnoDB? Почему вы даже используете файл в таблице? На самом деле это очень сложно, вы создадите так много открытых файловых дескрипторов и полностью уничтожаете интерфейсы вашей ОС, которые учитывают их и управляют ими. Если вас беспокоит использование пространства, которого вы абсолютно никогда не должны использовать, используйте Percona и TokuDB.Тем не менее, это известный факт, что вы хотите иметь достаточную ОЗУ, чтобы вставить свой набор данных в него для правильного и быстрого доступа. Почему вы беспокоитесь о сохранении дискового пространства? Таким образом вы убиваете оптимизацию двигателя. –
Проблема с InnoDB вполне реальна, и полу-решение innodb_file_per_table используется часто, см., Например, http://stackoverflow.com/questions/3456159/how-to-shrink-purge-ibdata1-file-in- mysql Я видел, что файлы ibdata1 увеличиваются непропорционально быстро. Вот почему я спрашиваю о XtraDB – jdrew