存储引擎（Storage engine）.doc

存储引擎（Storage engine） Lets take a look at the MySQL Architecture s Logical (MySQL) Figure 1 The first layer, the top layer, contains services that are not unique to MySQL. They all serve the C/S program, or what these programs need: connection processing, authentication, security, and so on. The second layer deserves attention. This is the core part of MySQL. Usually called SQL Layer. In the MySQL database system to handle all the work before the data are in the layers, including the authority to determine the SQL analysis, plan optimization, query cache and all the built-in function (such as the date, time, math, encryption and so on). The functions provided by each storage engine are focused on this layer, such as stored procedures, triggers, views, and so on. The third layer includes the storage engine. Commonly called StorEngine Layer, that is, the underlying data access operations implementation section is made up of a variety of storage engines. They are responsible for storing and acquiring all data stored in the MySQL. Just like Linuxs many file systems. Each storage engine has its own advantages and disadvantages. The server interacts with them by storing the engine API. This interface hides different storage engines. Make the query layer as transparent as possible. This API contains many low-level operations. Such as starting a thing, or taking out a row with a particular primary key. Storage engines cannot parse SQL, nor can they communicate with each other. Just a simple response to server requests. Connection management and security Inside the server, each client connection has its own thread. The query for this connection is executed in a separate thread. These threads run alternately in a CPU kernel (multicore CPU) or CPU. The server caches threads, so there is no need to create and destroy threads individually for each client connection. When clients (that is, the application) is connected to the MySQL server. The server needs to authenticate it (Auth