Without getting into the rest of your argument, I'd like to quickly address this.
No, it really isn't.
In your typical MySQL database, your performance for a simple "select * from x where y" is going to go through a lot of complicated machinery (most of which can be tuned for performance), a few points of which I will enumerate below.
1) Acquire a query cache lock & see if this query is there
2) Run the query through the optimizer
2a) Perform multiple shallow dives into a table to look at the cardinality of the filtered columns
2b) Identify the best indexes based on the shallow dives
2c) Create a query plan
3) Push the query plan down into InnoDB
4) Load the index into memory, if its not already there
5) Load the potential rows into memory, if they are not already there
5a) If there's not enough memory, load a few into memory, and be ready to push those rows out of memory in favor of more rows when needed
5b) Load rows that are still in the insert tree but not yet part of the regular buffer pool or pages on disk
6) Loop through the candidate rows for matches to the filter
7) Return the data to MySQL
8) Acquire the query cache lock & update it
9) Return the data to the client
Any and all of these can (and often should) be tuned. There are 600+ page books and very old (and oft updated) blogs dedicated to this topic... it's not something you can teach a developer in a couple of days.As an example, I attended an introductory course to being a MySQL DBA; it lasted 5 days of 8-5 teaching & running examples. And it only scratched the surface of what I do on a daily basis.