It's definitely a good idea to have prior general knowledge of database internals before reading an "internals" book.
I'm not sure if it's out of date, but my favorite book on the topic was "Database System Implementation" by Garcia-Molina et al. I found it to be super-readable.
What I like about the "internals" book is you get to see a real, specific database up close, warts and all. It gives you a different perspective from an overview book like the one mentioned above.
Additionally, I don't see how the need to know about the internals of MySQL means one should use a better database. PostgreSQL is normally proposed as the better alternative to MySQL if one sticks to Open Source, and all the good experts at it I have met were familiar with its internals too.
I think your last sentence is what caused me to misinterpret you. I agree with your comment up to "... being a good database.", but I think the point at which you need to know the internals of MySQL are irrelevant to whether you should use a database that is better for the problem you're trying to solve or not.
An equivalent substitution for another database would be fine; anyone have any suggestions? Then again, such a substitution is really solving a non-problem.
IMHO, MySQL is especially ugly due to an attempt to insert an abstract interface around its storage engines. IIRC that interface is leaky, and its documentation is pretty spotty. Also, the InnoDB storage engine has a lot of complexity that seemingly duplicates what's provided on the storage-engine-agnostic side of that interface.
One of the big lessons I took away from studying MySQL's internals, and partially confirmed by the "internals" book, was this: Be careful when designing a plugible storage-engines framework for a DBMS; MySQL has some examples of what can go wrong.
That's something you're unlikely to find mentioned in a generic DBMS-implementation book, but is very good to know about regardless.
