How does he avoid these issues affecting the mining itself then (i.e. registering shares) ? I mean, that in itself sounds like a lot of DB-traffic as well.
Last time this happened, he posted his issue here:
http://pastebin.com/TQ206qQjHis share table inserts one row for EVERY share submitted by EVERY miner. This table has 4 indexes on it. This makes every insert or update expensive on the I/O. His stats query then does a select count(shares.*) from ALL THOSE shares, further hammering his I/O while shares are still being submitted. This is a classic database paradigm with many ways to solve it. Some very easy!
H20, please reply to my PM. Database optimization is my day job. I can help.