High Performance MySQL [Electronic resources] نسخه متنی

2.1 MySQL Architecture

It
will greatly aid your thinking about storage engines and the
capabilities they bring to MySQL if you have a good mental picture of
where they fit. Figure 2-1 provides a logical view
of MySQL. It doesn't necessarily reflect the
low-level implementation, which is bound to be more complicated and
less clear cut. However, it does serve as a guide that will help you
understand how storage engines fit in to MySQL. (The NDB storage
engine was added to MySQL just before this book was printed. Watch
for it in the second edition.)

Figure 2-1. A logical view of MySQL's architecture

The topmost layer is composed of the services that
aren't unique to MySQL. They're
services most network-based client/server tools or servers need:
connection handling, authentication, security, etc.

The second layer is where things get interesting. Much of the brains
inside MySQL live here, including query parsing, analysis,
optimization, caching, and all the built-in functions (dates, times,
math, encryption, etc.). Any functionality provided across storage
engines lives at this level. Stored procedures, which will arrive in
MySQL 5.0, also reside in this layer.

The third layer is made up of storage engines.
They're responsible for the storage and retrieval of
all data stored "in" MySQL. Like
the various filesystems available for Linux, each storage engine has
its own benefits and drawbacks. The good news is that many of the
differences are transparent at the query layer.

The interface between the second and third layers is a single API not
specific to any given storage engine. This API is made up of roughly
20 low-level functions that perform operations such as
"begin a transaction" or
"fetch the row that has this primary
key" and so on. The storage engines
don't deal with SQL or communicate with each other;
they simply respond to requests from the higher levels within MySQL.