Let us say that was true. (It isn't, but let's pretend.) MySQL is faster than PostgreSQL or Ingres, correct?
Then use PostgreSQL or Ingres for your primary storage DB, and use MySQL to store cached responses. (Key issues, etc, are then a non-issue - you don't need a vast key to identify a cached pre-generated page.) You then get the full power of a complex DB with the performance of a lightweight DB.
Wait, isn't this what NoSQL databases are used for? Well, duh. Where do you think they got the idea? The rest of the world has been using multi-tier databases for a very long time now, and obviously if you want extremely high performance and only a simple key/value search for your highest-level DB, then why not use a system that is purely key/value?
The problem with NoSQL databases is that they can be a little TOO simple. You'll often want web pages where -some- of the content is universal, -all- of the content is cacheable, but where different content in some div block is used for different users (or different parameters or whatever). For something programmatic like that, you -could- use a language like Cold Fusion. Which, like its namesake from Utah, has no redeeming value whatsoever. It's much better to do something like this in a database engine rather than in an interpreter running in a servlet inside an interpreter, as procedures can be pre-compiled.
But if you want to do this, isn't MySQL still heavier than necessary? Oh, lots. What you really want is (NoSQL || (GDBM/QDBM + Network Access)) + Loadable modules. That's about as lightweight as you can get.
In an "ideal" system, you'd actually have three layers, not two. The lowest level should also be lightweight, but not MySQL lightweight. It wants to load/save data and create views, but having stored procedures on there as well complicates load balancing and high availability. It also means more arcs through the code, and each arc you add is a potential source of bugs. The lowest level wants to be rock steady (though ska will also work), feeding to the servers that do the heavy lifting. That way, database bugs (inevitable, it's complex code) will have no significant impact on transactions, each component in the system is highly specialized (so makes fewer decisions, so is smaller, faster and more reliable), and the critical path of any given transaction is blocked by as few incidentals and overheads as possible.
Tight coupling of components is only a good idea when components run at roughly the same speed and aren't particularly blocking. The greater the speed disparity or the greater the thread blocking, the more you want loose coupling or complete decoupling. Lacking dynamic reconfiguration, you layer things so that each layer will mostly have just one type of behaviour and the adjoining layers also mostly have just one type of behaviour. There will be exceptions, nothing is optimized for all cases, but if you get most of the available performance under most of the conditions that arise, you're ahead of most of the game.
The other reason you want multi-tier is for security. Everyone makes mistakes in coding, so you can expect some component of your system to be vulnerable to attack. If it's a component that an attacker cannot reach (because it's effectively firewalled by the databases above it), it's not an issue. If it's a component that an attacker can do nothing with (because all that's being attacked is cached data that will be refreshed from further down after some time interval or when the data below changes), then only those who hit that specific load balancer in the few seconds of significance will see the defaced data. Moments later, the correct data will replace it.