Totally depends on the use case I suppose, we found that in our environment, we perform _a lot_ more SELECT's than we do UPDATE/DELETE/INSERT's.

And with some badly optimized SELECT's, the time MySQL had to spend on sorting results/reading from disk in an inefficient way made all our _write_ queries suffer.

By optimizing our SELECTs first, we freed up some CPU bandwidth (it seems?) that can be spent doing all the other work.

That's good to hear. We have found some suspect SELECTs used in our client-facing API recently. Might be good to double-check that those are running efficiently and not hamstringing the writes.

If you misuse a database you will have a lot more complex SELECTs than UPDATEs perhaps ;-)