> "Understanding MySQL Internals"
Why this, as opposed to a more general text on databases? MySQL is popular, but few would accuse it of actually being a good database. I feel like the point at which knowing about the internals of MySQL becomes relevant is probably the point at which you should use a better database.
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.
I think a good book that helps you understand a complex piece of software is a good read for programmers, regardless of the use you make of that software.
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.
You seem to have misinterpreted my objection. There are better books on databases, and MySQL is not necessarily a good example of a database. It tends to do things in its own way. When you get into the sort of situation where the difference between 'how MySQL does things' and 'how things are supposed to work' matters, then typically it's MySQL that's quirky.
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.
I would assume that any book about the internals of a database would be suitable. MySQL is plenty real enough to be educational to learn about its internals, yea verily, even its quirks, and to learn a lot about how other databases work. Even the "NoSQL" databases will use many of the same primitives.
An equivalent substitution for another database would be fine; anyone have any suggestions? Then again, such a substitution is really solving a non-problem.
It may very well be the case that looking at the internals of some database other would provide a different set of lessons.
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.
