1. Select statement execution process
The execution process of a select statement is shown in the figure above
1. Establish a connection
The connector will check whether the user name and password you entered are correct, and will return a prompt if it is wrong. If it is correct, the connector will query the permissions of the current user. The role of the connector is to verify user permissions
2. Query cache
There is a concept of cache in MySQL. When you execute a SQL query statement, MySQL will first go to the cache to check whether there is a corresponding record. If there is, it will return it directly. If not, it will query from the database. After the query is completed Then put it in the cache. The purpose of this query cache is to speed up MySQL queries.
It is recommended that you turn off this cache option, because in actual projects, this query cache is not very useful, why do you say that. Because when an update or delete statement is executed, the query cache of this table will be invalidated, and the next query still needs to be queried from the database, so generally speaking, the query cache cannot improve performance.
3. Analyzer
The role of the analyzer is to perform lexical analysis and grammatical analysis. For the select statement, after getting this SQL statement, MySQL recognizes the select keyword, knows that it is a query statement, and then takes and identifies from and table names, and identifies fields. This step is lexical analysis. After the lexical analysis is completed, you need to perform grammatical analysis, that is, to judge whether the grammar of this statement is correct. For example, if you write select as selct, then the grammatical analysis will check it out.
4. Optimizer
The responsibility of the optimizer is to optimize the sql statement, such as what index should be used for this statement, and whether the sql order needs to be adjusted.
5. Actuator
After the above analysis, we came to the executor and started to query data from the database. Before querying data, it will check whether there is permission for the table, and if not, an error message will be returned. If you have permission, start scanning rows to see if the conditions are met, and the results that meet the conditions are placed in the result set.
2. Update statement execution process
The execution process of the update statement is the same as that of the select statement, and it also needs to go through the steps of connection, analyzer, optimizer, and executor. The difference is that two logs are involved in the update execution process, one is redo log and the other is binlog
redo log
First of all, it needs to be clear that the redo log is unique to the Inndb storage engine, and other engines do not. The main function of redo log is记账
To give an easy-to-understand example, you are the shopkeeper and you have opened a shop. The business of the shop is very good. Many people come every day. It records who owes you how much money. When the store first opened, there were few customers. It was no problem for you to record it in one pen. Later, when there were more customers, you found that it was time-consuming to look up the ledger, which affected efficiency. So you found a blackboard and the customers came. After paying, how much money you spend, you record it on the blackboard, and when you are not busy, you will summarize it on the ledger.
The blackboard here is the redo log, and the ledger is the MySQL database disk. The reason for this is to improve efficiency. Otherwise, every operation of MySQL will be written to the disk, which is very inefficient. With the redo log, every update operation, I only need to write to the memory, and then record to the redo log to return, which is much faster. When it is free, write the data in the redo log to disk for persistence.
InnoDB's redo log has a fixed size. For example, it can be configured as a set of 4 files, each with a size of 1GB. Then this "pink board" can record operations of 4GB in total. Start writing from the beginning, and then return to the beginning and write in a loop at the end, as shown in the figure below.
write pos is the position of the current record, it moves backward while writing, and returns to the beginning of file 0 after writing to the end of file No. 3. checkpoint is the current position to be erased, and it is also moved backwards and cyclically. Before erasing the record, the record must be updated to the data file.
Between write pos and checkpoint is the part of the "pink board" that is still free and can be used to record new operations. If the write pos catches up with the checkpoint, it means that the "pink board" is full, and no new updates can be performed at this time. It must stop and erase some records first, and advance the checkpoint.
With the redo log, InnoDB can ensure that even if the database restarts abnormally, the previously submitted records will not be lost. This capability is called crash-safe .
To understand the concept of crash-safe, think about our previous example of credit records. As long as the credit record is recorded on the pink board or written in the account book, even if the shopkeeper forgets it later, for example, the business is suddenly closed for a few days, after the business resumes, the credit account can still be clarified through the data in the account book and the pink board.
binlog
The redo log mentioned above is the log of the engine layer, and the binlog is the log of the MySQL Server layer
binlog is mainly to record the original operation statement of MySQL, such as update user set name = "Zhang San" where id = 2, binlog will record it
The difference between binlog and redolog
- Redolog is a log at the engine level, which is unique to Inndb, and binlog is at the Server layer, which can be used by all engines
- Redo log is a physical log, which records "what modification was made on a certain data page"; binlog is a logical log, which records the original logic of this statement, such as "Add 1 to the c field of the row ID=2" .
- The redo log is written in a loop, and the space will always be used up; the binlog can be appended. "Append write" means that after the binlog file is written to a certain size, it will switch to the next one, and will not overwrite the previous log.
two-phase commit
The internal flow of update statement execution
update user set name = "张三" where id = 2
- The executor first looks for the engine to fetch the line with ID=2. ID is the primary key, and the engine directly uses tree search to find this row. If the data page where the line ID=2 is located is already in the memory, it will be returned directly to the executor; otherwise, it needs to be read from the disk into the memory first, and then returned.
- The executor gets the row data given by the engine, and changes this value to Zhang San
- The engine updates this row of new data into the memory, and at the same time records the update operation into the redo log, and the redo log is in the prepare state at this time. Then inform the executor that the execution is complete and the transaction can be submitted at any time.
- The executor generates a binlog of this operation and writes the binlog to disk.
- The executor calls the commit transaction interface of the engine, and the engine changes the newly written redo log to the commit state, and the update is completed.
The two-phase commit is to submit the redolog first, then write to the binlog, and then submit the redolog after the binlog is successfully written