MySQL Performance Blog

Well these days we see a lot of post for and against (more, more) using of MySQL and DRBD as a high availability practice.

Let us talk few more about disks. You might have read my previous post and Matt’s Reply and it looks like there are few more things to clarify and explain.

Friday after MySQL Users Conference we had a smaller meeting at Google campus to talk about MySQL architecture mainly focusing on storage engine vendors and other extension areas.

Sometimes you have the task of storing multiple of boolean values (yes/now or something similar) in the table and if you get many columns and many rows you may want to store them as efficient way as possible.
For MyISAM tables you could use BIT(1) fields which get combined together for efficient storage:

In one of his recent posts Vadim already gave some information about possible benefits from using new InnoDB file format but in this post I’d like to share some real-life example how compression in InnoDB plugin could be useful for large warehousing tasks.

Have you ever run a query in MySQL and wondered how long it'll take to complete? Many people have had this experience. It's not a big deal until the query has been running for an hour. Or a day and a half. Just when IS that query going to finish, anyway?

There are actually a few ways to estimate how long it'll take for the query to complete, depending on what the query is. One of the simplest is to estimate how many rows the query needs to examine, measure how fast it's working, and do the math.

For a couple of months there have been no updates to our msl patch, however recently I managed some time to change this. The functionality was extended a little bit and what’s even more important the patch is available for all the recent MySQL releases.

MySQL Users Conference 2008 has number of Storage Engines presented which claim to Kick Ass. Walking in exhibition hall you could see KickFire, Infobright, Tokutek, ScaleDB. I have not seen NitroDB in the exhibition call this year but they are also worth to mention.
It is interesting to see all of them showing benchmarks with great numbers and glossy marketing materials explaining why they are better.

Looking into InnoDB docs I found list of names of future InnoDB file formats: Antelope, Barracuda, Cheetah, Dragon, Elk, Fox, Gazelle, Hornet, Impala, Jaguar, Kangaroo, Leopard, Moose, Nautilus, Ocelot, Porpoise, Quail, Rabbit, Shark, Tiger, Urchin, Viper, Whale, X, Y and Zebra.

Aren’t there animals starting on X and Y?

Reading evening news and rss feeds I found interesting next sequence:

Jeremy’s post “MySQL to launch new features only in MySQL Enterprise“

basically about some new features of MySQL will be available only for paid customers

Yesterday we started the conference early with MySQL Community Dinner which was quite a success with about 30-50 people showing up (hard to count as people come and go) even though it was conflicting with Silicon Valley MySQL Meetup and which at least prevented Jeremy and his team showing up.

We were doing MySQL Performance evaluation on TPC-H queries for the client and they kindly allowed us to publish results which are very interesting.
This is obviously not audited TPC-H run, and it can’t be because we used MyISAM tables which are not ACID complaint. Plus we only measured Power to keep things simple.