Scribd
Upload
17 views3 pages

High Performance MySQL-trang-2

MySQL's architecture is distinct, featuring a flexible storage-engine design that separates query processing from data storage, making it suitable for various applications. The document outlines MySQL's logical architecture, connection management, optimization processes, and concurrency control mechanisms. It aims to provide a comprehensive understanding of MySQL for both newcomers and experienced users of other database systems.

Uploaded by

Thường Nguyễn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
17 views3 pages

High Performance MySQL-trang-2

MySQL's architecture is distinct, featuring a flexible storage-engine design that separates query processing from data storage, making it suitable for various applications. The document outlines MySQL's logical architecture, connection management, optimization processes, and concurrency control mechanisms. It aims to provide a comprehensive understanding of MySQL for both newcomers and experienced users of other database systems.

Uploaded by

Thường Nguyễn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

CHAPTER 1

MySQL Architecture and History

MySQL is very different from other database servers, and its architectural characteris-
tics make it useful for a wide range of purposes as well as making it a poor choice for
others. MySQL is not perfect, but it is flexible enough to work well in very demanding
environments, such as web applications. At the same time, MySQL can power embed-
ded applications, data warehouses, content indexing and delivery software, highly
available redundant systems, online transaction processing (OLTP), and much more.
To get the most from MySQL, you need to understand its design so that you can
work with it, not against it. MySQL is flexible in many ways. For example, you can
configure it to run well on a wide range of hardware, and it supports a variety of data
types. However, MySQL’s most unusual and important feature is its storage-engine
architecture, whose design separates query processing and other server tasks from data
storage and retrieval. This separation of concerns lets you choose how your data is
stored and what performance, features, and other characteristics you want.
This chapter provides a high-level overview of the MySQL server architecture, the major
differences between the storage engines, and why those differences are important. We’ll
finish with some historical context and benchmarks. We’ve tried to explain MySQL by
simplifying the details and showing examples. This discussion will be useful for those
new to database servers as well as readers who are experts with other database servers.

MySQL’s Logical Architecture


A good mental picture of how MySQL’s components work together will help you un-
derstand the server. Figure 1-1 shows a logical view of MySQL’s architecture.
The topmost layer contains the services that aren’t unique to MySQL. They’re services
most network-based client/server tools or servers need: connection handling, authen-
tication, security, and so forth.
The second layer is where things get interesting. Much of MySQL’s brains are here,
including the code for query parsing, analysis, optimization, caching, and all the

1
Figure 1-1. A logical view of the MySQL server architecture
built-in functions (e.g., dates, times, math, and encryption). Any functionality provided
across storage engines lives at this level: stored procedures, triggers, and views, for
example.
The third layer contains the storage engines. They are responsible for storing and
retrieving all data stored “in” MySQL. Like the various filesystems available for GNU/
Linux, each storage engine has its own benefits and drawbacks. The server communi-
cates with them through the storage engine API. This interface hides differences
between storage engines and makes them largely transparent at the query layer. The
API contains a couple of dozen low-level functions that perform operations such as
“begin a transaction” or “fetch the row that has this primary key.” The storage engines
don’t parse SQL1 or communicate with each other; they simply respond to requests
from the server.

Connection Management and Security


Each client connection gets its own thread within the server process. The connection’s
queries execute within that single thread, which in turn resides on one core or CPU.
The server caches threads, so they don’t need to be created and destroyed for each new
connection.2
When clients (applications) connect to the MySQL server, the server needs to authen-
ticate them. Authentication is based on username, originating host, and password.

1. One exception is InnoDB, which does parse foreign key definitions, because the MySQL server doesn’t
yet implement them itself.
2. MySQL 5.5 and newer versions support an API that can accept thread-pooling plugins, so a small pool
of threads can service many connections.

2 | Chapter 1: MySQL Architecture and History


X.509 certificates can also be used across an SSL (Secure Sockets Layer) connection.
Once a client has connected, the server verifies whether the client has privileges for
each query it issues (e.g., whether the client is allowed to issue a SELECT statement that
accesses the Country table in the world database).

Optimization and Execution


MySQL parses queries to create an internal structure (the parse tree), and then applies
a variety of optimizations. These can include rewriting the query, determining the order
in which it will read tables, choosing which indexes to use, and so on. You can pass
hints to the optimizer through special keywords in the query, affecting its decision-
making process. You can also ask the server to explain various aspects of optimization.
This lets you know what decisions the server is making and gives you a reference point
for reworking queries, schemas, and settings to make everything run as efficiently as
possible. We discuss the optimizer in much more detail in Chapter 6.
The optimizer does not really care what storage engine a particular table uses, but the
storage engine does affect how the server optimizes the query. The optimizer asks
the storage engine about some of its capabilities and the cost of certain operations, and
for statistics on the table data. For instance, some storage engines support index types
that can be helpful to certain queries. You can read more about indexing and schema
optimization in Chapter 4 and Chapter 5.
Before even parsing the query, though, the server consults the query cache, which can
store only SELECT statements, along with their result sets. If anyone issues a query that’s
identical to one already in the cache, the server doesn’t need to parse, optimize, or
execute the query at all—it can simply pass back the stored result set. We write more
about that in Chapter 7.

Concurrency Control
Anytime more than one query needs to change data at the same time, the problem of
concurrency control arises. For our purposes in this chapter, MySQL has to do this at
two levels: the server level and the storage engine level. Concurrency control is a big
topic to which a large body of theoretical literature is devoted, so we will just give you
a simplified overview of how MySQL deals with concurrent readers and writers, so you
have the context you need for the rest of this chapter.
We’ll use an email box on a Unix system as an example. The classic mbox file format
is very simple. All the messages in an mbox mailbox are concatenated together, one
after another. This makes it very easy to read and parse mail messages. It also makes
mail delivery easy: just append a new message to the end of the file.

Concurrency Control | 3

You might also like