3.2.0 DP2 InnoDB

Is there any concern with mixing the tables with new tables going forward being InnoDB and original tables being MyISAM?

It’s mostly an operations nuisance in the sense that things like backups don’t work the same. They are both prevalent enough that a shared host will be optimized to handle both. If you’re running a very large site we recommend talking to your host, but many of the largest sites are already on InnoDB anyways, mainly due to write lock contention on MyISAM.

What are the dangers of mass converting all tables in the DB to InnoDB? I did it on my test install, but there is very limited sample data there.

No real dangers for the first party tables, but with third party tables you have to be careful that none have fulltext indexes (we used to have one which we’re dropping as part of this update). For that same reason, any code that specifies a storage engine on table creation will not be forced to use InnoDB.

Since it can be hard to tell if an existing table is using MyISAM on purpose, or simply because it was the default, we don’t want to risk converting all tables in the updater. On a large site this might also be prohibitively slow to do in a PHP script. And lastly, if you’re running a large site then the read heavy tables that MyISAM is optimized for should not be converted without talking to your host. Database configuration at scale is a tricky thing.

We will have documentation for how to do the conversion for those that want to do it.

Is there a way to set the default engine from config? Maybe sites being updated from older installs with MyISAM tables should remain that way and set it so in the config?

It’s something to consider. Table creation is relatively rare inside the application so we’re not too concerned.