Xaprb

With all the furor over MySQL 5.1 GA, its release schedule, its quality, etc etc I think a fundamental claim is being left un-examined. Lots of people are saying that if you leave out the new features in 5.1 and look only at the features that existed in 5.0, it’s better quality.

The implication is that the process of building 5.1 looked like this: rip out nasty code and fix it all up, so there’s a brand new architecture free of code debt. Adjust existing features to use this new, high-quality, sensible server architecture. Add new features.

Is this accurate?

Time will tell, and I have not yet seen enough of 5.1 in real-world production environments. As Peter says, it’s not how many bugs there are — it’s how many bugs affect you. In my line of work, we see bugs that only show up if you’re, for example, running a server with hundreds of thousands of tables. Or similar edge cases. I see a lot of routine things, too, but my point is that I am somewhat reserving my opinion about 5.1’s quality of existing features. As an example of what I mean, there were some bugs with 5.1 not using indexes correctly — a serious regression from 5.0. These have been fixed. Will there be others that haven’t been found yet? Probably.

Here is my gut feeling about a few existing features: triggers were always a hack and remain a hack. The memory allocation algorithms of the query cache are suboptimal, and that hasn’t changed fundamentally. Geospatial functions are largely unusable, and that hasn’t improved. The silly behavior of correlated subqueries has probably been MySQL’s number one slap-me-in-the-forehead misfeature since it was introduced in 4.x, and that isn’t fixed (it will be in 6.0, but that’s a whole other topic). Failsafe replication is code rot that was partially implemented and then abandoned in 4.x, causes bugs, and they haven’t even removed the code (read the bug report!). UNION still uses a temporary table, whether it’s required or not. LOAD DATA FROM MASTER never worked to begin with, and it’s still there — it causes problems and should be ripped out. The Federated engine is probably best left alone. Group commit is still broken for InnoDB when binary logging and XA transactions are enabled. (This was broken during 5.0’s release, is a serious regression since 4.1, and is definitely a server architecture problem. So much for the beautiful new server architecture in 5.1?)

Don’t get me wrong. I’m not trying to bash 5.1’s quality. I’m just taking issue with this unchallenged assertion that everything that wasn’t introduced in 5.1 is rock solid, performs better, and works beautifully now. I don’t know for sure; I suspect it is partially true and partially false, but time will tell.

I will say this: I’m generally happier with the quality and stability of 5.0 in the last little while, say since 5.0.6x. If you don’t need 5.1’s new features, why break something that works?

O’Reilly tells me that translation rights for our book, High Performance MySQL Second Edition have been purchased in the following languages:

• Korean
• Russian
• Portuguese
• Polish
• Spanish
• Czech

Some of them were sold quite a while ago, and some are more recent. Portuguese was the first. I’m looking forward to learning all these languages (except for Spanish, which I already sort of know) so I can read the book in them… in my copious spare time!

Download Maatkit

The December release is here! There are some goodies in this release, but the major one is an initial version of mk-log-parser, a slow log analysis tool that is carefully designed (with lots of input from Percona consultants) to make slow log analysis as productive and easy as possible. It’s based on a lot of work Daniel and I have done on log analysis over the years (I actually wrote the initial version a long time ago but never released it). Our goal is to finally put all the mostly-good-enough log parsing tools to rest. There are bugs, we know that; but we’d like you to use the tool and give us feedback anyway.

We also made mk-audit a little more robust, although we didn’t really start to touch the massive TODO list for it. And we fixed a few bugs in mk-table-checksum and mk-table-sync, as well as making them more efficient.

As usual, please use the mailing list and issue system for anything but compliments.