Следует учитывать, что конвертация больших таблиц может быть очень длительной, поэтому оптимальным будет исключить из конвертации помесячные таблицы с сессиями, наработками и т.п. Для транзакционной работы они не критичны. Достаточно, что в последующие месяцы эти таблицы также будут создаваться в формате InnoDb.

Осталось ещё понять магический смысл опции "innodb_file_per_table"

Учитывая, что engine в mysql работает не на уровне "per-database" , а на уровне "per-table", может имеет смысл где-нибудь предусмотреть конфигурацию списка таблиц, подвергающимся переводу на innodb лил остающимся в старом формате ?

Единственно для возможности бакапа с помощью снапшотов и rsync.

Кроме таблиц, которые могут быть вынесены в "Мусорную" БД всё постепенно переводить в InnoDb.

Простите, а почему все-таки innodb, ведь есть угроза что oracle откажется от этого стораджа... да и проблемы в нем с локами огромные. И производительность - ниже и ресурсов надо больше... И io - если мне не изменяет память - тоже очень вырастает...

Возможность работы с транзакциями . В 5.2 вообще код написан с учетом транзакцией, будет работать только на innodb. Почему откажется ?

По поводу слухов вокруг innodb:

http://twitter.com/#!/jwage/status/29650830060
http://habrahabr.ru/blogs/mysql/107559/

А вообще, innodb требует очень много оперативной памяти, и очень нетривиальных настроек, полагаю вендор биллинга - не уделяет анимание mysql backend`у, дает все на откуп пользователей. Что совершенно неверно. Этому вопросу необходимо посвятить очень много времени, т.к. в случае перехода и перевода на innodb больших операторов - проблемы неизбежны. Одни только потерянные инсерты чего стоят... такого не получить в myisam. Простое копирование файлов - уже не бекап. В общем очень большое кол-во вопросов возникает при переходе на innodb. Естественно, не при таблицах в 1 Мб.

Сейчас работает несколько крупных операторов на innodb и уже давно . И не жалуются .

А потом как у людей будут проблемы, наиболее страшная - это потеря инсертов... они буду говорить что это не мы, а mysql - настраивайте его сами. Вот то что предвосхищаю.

Помоему, это хорошо, что есть альтернативная БД, которая, по слухам, быстрее и надежнее и при этом полностью совместима с mysql.
Но в 5.2 на нее мы точно переходить не будем, т.к. пока даже не было времени эту БД тестировать.

А вот с этого момента по подробней.

В оракловых форумах - очень много упоминаний об этом. Там же есть очень много наработок в сторону Maria.

в официальной документации должен быть раздел по настройке MySQL с innodb engine с четким руководством, что и как делать кратким переводом этой статьи и обязательной ссылкой на мануал

Так?

Биллинг, например, еще с cisco работает. В документации тоже нужно излагать подробный мануал по настройке cisco ?

Ну вот мы и включили в 5.2 документацию ссылку на Wiki, где официально описаны рекомендации.
В плане настройки Innodb даже проще, чем MyIsam. Там всего одна опция под память innodb_buffer_pool_size
и под количество процессоров innodb_thread_concurrency. Не нужно отдельно выделять под индексы, данные и т.п.
Остальные параметры оставляются как в примере.
Памяти и места на диске он поглощает изрядно, конечно. Места на диске примерно в 2 раза больше, чем MyIsam.
Но зато получается реальный прирост производительности. Мы проверили на действующих операторах.
Нет блокировок уровня таблицы, используется буферизация часто используемых записей в ОЗУ.
MyIsam плох тем, что он летает-летает-летает а при определённой критичной нагрузке просто затыкается насмерть.
И заставить его что-то буферизировать не получается, от добавления памяти скорость не растёт.
Innodb в этом плане гораздо лучше. Количество выполняемых запросов в единицу времени не падает при росте нагрузок.

Т.е. другими словами, мы (пользователи) не получим более детальную настройку mysql с движком innodb окромя того что уже есть. Верно?
PS А ведь было бы неплохо получить уверенность в том, что все верно настроено, по документации, которую подготовил производитель.

А чем вас сейчас данная дока не устраивает? ее переделали, и на данный момент она вполне юзабельна и красива

Кххмм.... вы вообще данную тему читали? В ней было высказано много опасений о innodb... Не хочется цитировать...