MySQL 5.5?

**Alfa1** · May 19, 2011

Would upgrading to mysql 5.5 and php 5.3 cause any issue with VW?

**pegasus** · May 19, 2011

We use PHP 5.3.5 here without any issues.

From the looks of the changelog for MySQL 5.5, I don't see any issues with VaultWiki if you're already on the latest version or are installing fresh. There is a compatibility issue with one vBulletin function that we use in earlier upgrade steps <= 3.0.1. I have reported the issue to vBulletin devs now, because they probably use it more frequently: http://tracker.vbulletin.com/browse/VBIV-12134

Another thing I would be concerned about in MySQL 5.5 is that InnoDB is now the default engine for new tables. From my experience, InnoDB tables crashed more than MyISAM tables with the same configuration did, even though InnoDB claims reliability. It also claims crash recovery, but every time I've seen an InnoDB table crash, it was not possible to recover without dropping the table and starting over (so use backups, still). Perhaps related to the following.

Another downside is that InnoDB uses a different INDEX structure than MyISAM. Indexes that aren't aligned with the PRIMARY KEY are much slower than their MyISAM counterparts, so InnoDB is only good for tables where data is fetched via ID or by a field that shares a key with the ID. If many new users are going to be moving to MySQL 5.5, then we need to change the installer to force MyISAM for certain tables.

**Alfa1** · May 19, 2011

You'll see on vb.com that IB staff is actively promoting (in blogs and posts) the use of MySQL 5.5 due to its performance benefits. See the performance blogs by Anders and various posts by Anders / Eva2000.

I was not planning to move from MyIsam to InnoBD, but am considering MySQL 5.5

**pegasus** · May 19, 2011

Well, if they are promoting it they better fix that compatibility issue. I would say I want to try it, by it looks like all the MySQL stuff takes < .02s on this page. PHP appears the bottleneck. Wish there was a way to make that faster. XCache reduced 50% but there's still room for improvement. I've been thinking it's probably disk seeks for each included file, but I was under the impression that XCache strings it all together and removes the extra seeks on cache-hits.