Databases Reference
In-Depth Information
also appreciate clean APIs inside the server. They help to promote higher-quality code,
and who doesn't want that?
Summary
MySQL has a layered architecture, with server-wide services and query execution on
top and storage engines underneath. Although there are many different plugin APIs,
the storage engine API is the most important. If you understand that MySQL executes
queries by handing rows back and forth across the storage engine API, you've grasped
one of the core fundamentals of the server's architecture.
MySQL was built around ISAM (and later MyISAM), and multiple storage engines and
transactions were added later. Many of the server's quirks reflect this legacy. For ex-
ample, the way that MySQL commits transactions when you execute an
ALTER TABLE
is a direct result of the storage engine architecture, as well as the fact that the data
dictionary is stored in
.frm
files. (There's nothing in InnoDB that forces an
ALTER
to be
nontransactional, by the way; absolutely everything InnoDB does is transactional.)
The storage engine API has its downsides. Sometimes choice isn't a good thing, and
the explosion of storage engines in the heady days of the 5.0 and 5.1 versions of MySQL
might have introduced too much choice. In the end, InnoDB turns out to be a very good
storage engine for something like 95% or more of users (that's just a rough guess). All
those other engines usually just make things more complicated and brittle, although
there are special cases where an alternative is definitely called for.
Oracle's acquisition of first InnoDB and then MySQL brought both products under
one roof, where they can be codeveloped. This appears to be working out well for
everyone: InnoDB and the server itself are getting better by leaps and bounds in many
ways, MySQL remains GPL'ed and fully open source, the community and customers
alike are getting a solid and stable database, and the server is becoming ever more
extensible and useful.
