Given a piece of SQL, do you know how it completes a process in MySQL?

Article Directory

- Given a piece of SQL, let's talk about its execution process!

Given a piece of SQL, let's talk about its execution process!

Drawing explanation

Briefly explain the components of the above picture

Connector : related to identity authentication and permission authentication (when logging in to mysql)
Query cache : When executing sql, it will first query the cache to see if there is any in the cache (removed after MySQL8.0, it is not very useful)
Analyzer : When there is no cache hit, it will enter this analyzer. To put it bluntly, just get your sql, analyze what you are doing, and check if your grammar is correct.
Optimizer : execute this SQL according to the best plan that MySQL thinks
Executor : execute the statement, and then get the data from the storage engine.

Briefly explain the layering of MySQL

MySQL is mainly divided into server layer and storage engine layer

Server layer: It mainly includes connectors, analyzers, optimizers, executors, etc. All cross-storage engine functions are in this layer. There is also a general binlog log module

Storage engine layer: various storage engines implemented by MySQL, including MyISAM, InnoDB, etc. Now InnoDB is used very much, after MySQL 5.5.5, the default storage engine is InnoDB

Sentence analysis

Having said that, how is a piece of SQL executed? SQL statements can be roughly divided into two types: query statements and update statements (insert, update, delete). First, let's introduce how the query statement is performed.

Check for phrases

Given a piece of SQL:

select * from t_student A where A.age=18 and A.name="张三";

When MySQL gets this SQL, it will perform the following process:

First go through the connector to query whether you have permission. If you don’t have permission, you will directly return an error message. If you have permission, you will query the cache. If there is a cache, you will return directly. If the cache misses, you will go to the next analyzer. Go in
When it comes to the analyzer, it will extract the keywords of this sql: select, t_student, etc., and then do the corresponding operations. In addition to this work, it will also check whether the sql has a syntax error, and if there is an error, it will directly return an error. Information, if there is no error, it will go to the optimizer

The optimizer will generate a specific SQL plan according to the best plan it thinks, such as this SQL, there will be two plans

1、先找出age = 18的数据，从这批数据中找出name=“张三”的数据
2、先找出name = “张三”的数据，从这批数据中找出age = 18的数据
优化器会根据它的算法得出最好的方案(但不一定是真正最优的方案)，交由执行器去执行。

Finally, it comes to the executor. It will first determine whether there is permission. If there is no permission, it will return an error message. If there is permission, it will call the storage engine interface, and then get the data and return it to the client.

Update statement

To give a piece of SQL:

update t_student A set A.age = 19 where A.name="张三";

In fact, its SQL execution process is similar to query, that is, when it is updated, it will involve the step of writing logs. MySQL will write this record to the binlog (archive log). All storage engines use this process, but Our commonly used InnoDB also comes with redo log (redo log), and also records redo log. Let's use the InnoDB engine to introduce the update process:

First perform a query operation to find this piece of data. If there is a cache hit during this period, get this piece of data from the cache, get this piece of data, and change its age to 19
After the age is changed to 19, InnoDB will write this operation record into the redo log, the redo log enters the prepare (pre-commit) stage, and then tell the executor that the execution is complete and it can be submitted at any time.
The executor receives the notification, records the bin log log, and then calls the engine interface to modify the redo log to the submitted state
update completed.

After reading the above steps, you may have the following questions :

Why does redo log enter the pre-commit state first instead of submitting it directly? If we directly enter the redo log into the commit state, and the machine is down when the bin log is not recorded, then there will be a problem. The records in the redo log and the data in the bin log are inconsistent, which will cause master-slave replication When the data is inconsistent, the local machine has this data, but the slave does not have this data. So use the pre-commit phase
Why write redo log first and then bin log? Can’t the other way around? If you write the bin log first, the machine is down after the writing is finished, and the redo log is not recorded, resulting in a logical loss of this piece of data (InnoDB cannot find this piece of data, but it actually exists). This is also a situation that leads to inconsistent data.
Can there be only one bin log record? Why join redo log? In fact, such a solution is also possible, but adding redo log is used by InnoDB to solve transaction problems. If transactions are not required, only the bin log is no problem.

to sum up

To summarize the above notes below:

MySQL is divided into Server layer and storage engine layer. The Server layer mainly includes connectors, query cache, analyzer, optimizer, executor and other components. There is also a log module bin log, which is a common one for all storage engines. Log module. The redo log is a unique InnoDB redo log used to solve transaction problems. The storage engine group includes common MyISAM and InnoDB and other storage engines
The flow of query statement execution SQL: executor -> permission check -> query cache, return on hit, miss -> analyzer -> permission check -> executor -> return result
Update the flow of statement execution SQL: executor -> permission check -> query cache, get the record when hit -> analyzer -> permission check -> executor ->redo log prepare ->bin log ->redo log commit