There's always a catch, right? Of course there is. One thing to take into account with database optimizations is that you don't optimize the database over the system it's running on. In other words, don't let it take up so much memory that the system is swapping memory to and from the hard drive swap space constantly.

I ran into this problem a few weeks ago with BanLink. The system was having all kinds of difficulties and then noticed that it'd gobbled up so much memory that it was spending half the time swapping the database cache from the disk cache.

Another catch, at least in my case, but I've read of a few others, is that MySQL will not *always* restart after you've changed the database settings. In other words, it shuts down fine, but just refuses to start. The solution I've found to this is to blank out the configuration, start it up, apply an updated configuration, and restart. It doesn't *always* work, and I don't even really understand why it should work, but it's about all I have to go on.

I experienced this a few weeks ago, only I couldn't get my new settings to take. No matter what I tried, the database refused to start with any optimized settings. So I just let it start up unoptimized. That worked. The stats on the site weren't even all that bad, so I let it run for a while.

That was short-lived, however. A good test of your optimizations are to run it without them for a while. Ok, that's a really poor test. Averaging around 10 seconds to respond was not a pretty thing. But I finally managed to get some of my new settings pushed into the database. We're back to sub-second responses, and we're not eating up all the memory of the system to do so.

The point? A good DBA pays attention to their database and doesn't let it win the battle…and it will fight you.