MyISAM 2 InnoDB - Changes tables engine from MyISAM to InnoDB
 

After reading Anders is blog: Part 1 vB4mance: Helping communities grow, performance data model changes in vB 4.0 Thanks Anders, I've decided to make a simple product to bring the power of InnoDB to anyone who wants it.

Just import the product and go to Maintenance->Update Counters and scroll down, more down, then you'll find Change tables engine to InnoDB

It can be used with 3.5 3.6 3.7 3.8 and 4.0, and I don't know if I should start a new thread in the "vBulletin 4.0 Add-ons".

Please make sure to back-up your database before doing this.

Enjoy.

Thank you! I'll wait to see if its functioning properly. Don't want my db to become corrupted.

There are the advantages?

...

How are you getting around the search issue?

<a href="http://www.yqed.com/mysql-storage-myisam-innodb-explained/" target="_blank">http://www.yqed.com/mysql-storage-my...odb-explained/</a>

This is a good read.

I skiped any FULLTEXT table. if I'm going to make this product for vb 4.0. I may skip only (searchcore_text, searchgroup_text) and maybe language

actuality, I may not need to skip any table, as MySQL well refuse to convert any table with FULLTEXT inside it.

Will, this looks more real to me :)
http://www.mysqlperformanceblog.com/...sam-to-innodb/

I have a few production systems which use innodb (the smallest is a 400gb reporting dbms). So far I only have two issues with them and I'm not sure how that would translate to vb usage: the resource overhead seems significantly higher for innodb, and , when necessary, innodb data recovery has a global impact.

resource overhead is an issue on my non-commercial vb system because i don't use a dedicated server and the demands of ajax database access alone kill it even using myisam.

the data recovery issue is more significant for me: when i have encountered a data structure corruption error (and it's not that frequent an occurrence; it only happened once in 2009) , the entire innodb database instance simply will not come up until the issue is addressed.

using myisam only the affected table(s) becomes unusable (not having foreign key constraints you just don't have the data integrity issues associated with foreign key violations), which makes recovery a simple matter of dropping the structure and reloading it from the most recent backup. since the entire innodb instance will not load when corruption is detected, recovering from a backup becomes unfeasible as reloading all 400GB of table data simply takes too long, so i employ snap mirroring with local protection (dbms redundancy). without these resources, i can't see using innodb with anything over 25gb. i would prefer to use oracle 10/11g for such systems, and as Oracle now owns innodb that's probably going to become the formal migration path over time, but i'll wait for oracle to add similar administrative functionality to innodb before i use it for larger databases.

gmerin!, haven't you tried to use "innodb_file_per_table"? No? Then you should read this one:
http://www.mysqlperformanceblog.com/...zation-basics/