Quote: "Would a MySQL reinstall not help?"
It's not running on windows you know - magical fixes like that don't exist on Linux servers. At least, as far as I can remember this is running on a Linux server... Perhaps an
optimise tables would help, but I'm guessing that's what happened during the downtime.
Richard Davey
Dunno if you've already tried this, but add in the following lines into my.cnf and do a graceful restart, a log will appear with all the queries which took longer than
long_query_time to complete.
[mysqld]
log_slow_queries=/var/log/slow-queries.log
long_query_time=2
Also, depending on how you measure CPU usage under linux, my understanding is that it can encompass a couple of bottlenecks. For example, if a process is always waiting for disk access, then that can contribute to its processor usage; the time spent on the process in question is longer because of slow disc access. So try out some profiling on disk, memory and CPU.
It also might be worth taking an offline backup of the tables and running a repair on them. Naturally, you couldn't use the repaired tables (because repairs can take days), but an analysis would show if MySQL is suffering from corrupted indices. When using myisamchk you pass in "-n" as a switch. This forces the repair to take place entirely on disk. Believe it or not, for large tables this is faster than using memory because the keys are not being paged in and out of memory all the time. I found this out when trying to repair a 55 million row table.
New 'n' Improved sig details how little I accomplish