Execution of a SQL update statement
1, update T set c=c+1 where ID=2;
1) The flow of the update statement is the same as that of the query statement, first connect to the database;
2) When there is an update on the table, the related table The query cache will be invalidated, and the cached results related to the table will be cleared;
3) The analyzer analyzes the syntax and determines that the syntax is an update statement;
4) The optimizer decides which index to use;
5) The executor executes the statement and finds the target row to update.
2. Unlike the query process, the update process also involves two important log modules, redo log (redo log) and binlog (archive log).
1) Every update operation of MySQL needs to be written to the disk, and the disk also needs to find the corresponding record before updating. The IO cost and search cost of the whole process are very high, so MySQL uses WAL (Write-Ahead Logging) technology to write the log first , and then write to disk.
2) When a record needs to be updated, the InnoDB engine first writes the record to the redo log and updates the memory. At the same time, the InnoDB engine will update the record in the redo log to the disk at an appropriate time, such as the system idle time.
The log module redo log and binlog
1. InnoDB’s redo log has a fixed size. It starts writing from the beginning, writes to the end and then returns to the beginning to write in a loop. write pos records the current writing position, and checkpoint records the erasing position.
1) The part between write pos and checkpoint can record new operations. When write pos catches up with checkpoint, new updates cannot be performed. It is necessary to update the record of the erase position to the data file first, and then record after performing the erase operation new operation.
2) With the redo log, InnoDB can ensure that the operation records will not be lost after the database restarts abnormally, which is called crash-safe.
2. The redo log is a log specific to the InnoDB engine, and the binlog is the server layer log, which can be used by all engines.
1) The redo log is a physical log, which records the modification on the data page, and the binlog is a logical log, which records the original logic of the statement; 2) The redo log is
circular writing, and the binlog is append writing, which will not overwrite the previous log.
3. The binlog will record all logical operations and adopt the form of append writing. If the system regularly backs up the entire database, the database can be restored to the state at any moment in the backup cycle.
1) First restore the database to the backup state before the specified time;
2) From the backup time point to the time to be restored, take the content in the binlog, and operate the data according to the extracted binlog to restore to the specified time.
Two-phase commit
1, update T set c=c+1 where ID=2;
1) The executor fetches the data with ID=2 through the engine, if the data page where ID=2 is located is in the memory, it will be directly returned to the executor, if If not, you need to read from disk to memory before returning.
2) The executor gets the data +1 returned by the engine, and then calls the engine interface to write the updated data.
3) The engine updates the new data to the memory, and records the update operation to the redo log. The redo log processes the prepare state and informs the executor that the execution is complete and the transaction can be submitted.
4) The executor generates binlog and writes binlog to disk.
5) The executor calls the engine to submit the transaction interface, and the engine changes the redo log to the commit state, and the update is completed.
2. In the last three steps, the redo log write is split into a two-phase commit of prepare and commit. Redo log and binlog are two independent logics. If there is no need for two-phase commit:
1) Write redo log first and then binlog. Assume that when the redo log is written and the binlog is not finished, the database restarts abnormally, and the binlog does not record the current operation. , and this operation is missing during the backup and recovery process, and the recovered data is different from the original database.
2) Write the binlog first and then the redo log. After the binlog is written, the crash occurs. The redo log is not written. The transaction is invalid after the crash recovery, but the binlog has recorded this operation, and there is an additional transaction in the subsequent backup and recovery. Recovery The output data is different from the original database.
3. Using two-phase commit, the state of the library restored according to the log is consistent with the original library.
4. Not only do backups and binlogs need to be used to restore data due to misoperations, but also full backups + binlogs are the common method when expansion is required to build a backup database. Inconsistent operations will lead to inconsistencies between the master and slave databases.
5. Compared with backup once a week, the longest recovery time is shorter. However, frequent full backups require more storage space, so the choice of backup time should be determined based on business evaluation.
1) In the best case, use one day's binlog to restore data to a certain moment;
2) In the worst case, use a week's binlog to restore data to a certain moment.