MySQL 5.161, часть таблиц MyISAM, основная часть InnoDB. InnoDB_file_per_table=false.
В виду специфики софта основные (и при этом самые большие) таблицы очень сильно фрагментированы. А в виду их достаточно больших размеров (50-150гигов каждая, включая индексы), количества индексов (до 8 штук на каждую) и круглосуточной работы БД регулярный OPTIMIZE всех таблиц сделать проблематично. Фрагментация выливается в общую загруженность дисковой полки с БД и другие беды.
Насколько корректна идея включить InnoDB_file_per_table, перестроить таблицы, где проводится больше всего циклов удаления и вставки (теперь они будут каждая в своем файле), а таблицы-справочники и таблицы MyISAM оставить в основном табличном пространстве?
Не будет ли снижение быстродействия или еще какой беды от такой частичной разборки?
И в каком варианте тогда оставлять InnoDB_file_per_table, true или false, после окончания перевода таблиц в отдельные файлы? Есть ли зависимость быстродействия от текущего значения этого параметра?

ScareCrowвы сами-то то поняли что сказали?

Увы, при совершенном понимании предмета темы данной темы не было бы.
И что я крамольного сказала?

alex564657498765453таблицы майисам храняться в отедльных файлах априори.
Каюсь... Почему-то всегда думалось, что они в ибдата1...

alex564657498765453,

>>у меня например проблема - как быстро сгенерировать таблицу подчинённую с индексами и внешними ключами на милиард записей(300 гигов получился файл, без ключей внешних).
ибо если ключи есть - медлено, ибо перестройка индекса постоянная, если ключи потом добавлять - мускл файл пересоздаёт и очень медленно - счас за сутки гдето 3-4гига обрабатываеться(рост нового файла что он создаёт)

Была и у меня такая проблема :)
Мою версию Мускула ускорить удалось только капитальным уменьшением кол-ва данных. Были опробованы варианты: создавать и заливать таблицу отдельно, потом строить индексы, заливать и строить одновременно, строить индексы не все сразу, а по одному, делать все вышеперечисленное на движке MyISAM а потом преобразовывать в InnoDB. Infile-outfile тоже пробовала. Как ни странно звучит, время на любой из вариантов затрачивалось примерно одинаковое :) Кстати, еще один рабочий вариант-уменьшить кол-во индексов. Построение каждого следующего индекса занимает раза в полтора больше времени (у меня даже формула, полученная опытным путем, где-то валялась). Percona с этой задачей хорошо справляется, но у меня не Percona :(

Теперь к моим баранам :)
>>насколько понял я, эта настройка для движка иннодб вцелом.. либо все хором, либо по одной.
ну почему? Какие таблицы перестроила, такие и в отдельные файлы пошли. Остальные остались.

>>задай со старта его с запасом, выключи мускл, дефрагментируй, и будет тебе счастье (если будет) - ввиде цельного файла *.ибд
не могу :( Процесс достаточно долгий, за одну ночь (даже если я ее выбью) не успею.

>>возможно будет полезно портиционирование данных в таблицах
проходили. По датам софт не поддерживает, дублирует данные. Другое распределение невостребовано. Да и таблицы сечас не такие большие, как раньше были.

>> вопрос автору - а как ты получил эти таблицы???
есть ряд таблиц, куда круглосуточно попадают продажи с касс. Из этих таблиц ежедневно удаляются данные старше N-месяцев. Удаление идет по каждой кассе конкретно, то есть из одной таблицы последовательно запускается удаление данных нескольких десятков, если не сотен касс. Одновременно с удалением продолжают поступать свежие данные с касс. Размер ежедневно удаляемых данных не равен ежедневно добавляемым.

>>то эта оптимизация тебе ничего не даст
optimize table немного уменьшает время запросов к данной таблице.
InnoDB_file_per_table- ожидаю, что уменьшится фрагментация. То есть в пределах одногь файла=таблицы фрагментация останется, если с ней не работать, а вот куски разных таблиц в ибдата1 уже перемешиваться не будут, и хотя бы индексы можно будет читать в один прием.