| > Virtually everything on that list are implementation details that the vast majority of applications and developers don't need to even think about. Particularly if you hire a DBA. But that's not what you meant... and you're right. If your business doesn't generate enough query traffic and data to stress your database, then no, you don't need more than the indexing and smart query development which your average developer can learn. The moment your business hits that wall, however, you'll be scrambling to get someone who can dig into those "implementation details" and wring every ounce of performance out of your database. > [...] do you think every query needs to be tweaked for this one: Push the query plan down into InnoDB Nope. However, for that one table that is better served by using Tokudb, or MyISAM, or the Archive engine it does matter (yes, there are actually use cases for using MyISAM tables instead of InnoDB). > 5a + 5b, Is MySQL so bad at memory management that you tweak it for every query? Again, for every query? No. Also, 5a and 5b have nothing to do with memory management, and everything to do with the size of the dataset you have to pull into memory to identify and return the results. Knowing how this affects the buffer pool LRUs, disk usage patterns, and how to optimize the interaction between the two can be vital. |
Just because you're a mechanic.
I said there is a bar when you will need a DBA. It is much, much, much higher than you're making out.
And the things you're talking about, most of the people mucking around with them probably shouldn't be. They've probably made it worse. Any the tiny few who actually need to? They're a tiny few.