[Mojah]

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.

[toshinoriyagi]

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.

[sebazzz]

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