"Ip Man" is to know the number of newly designed interactive part of the Church, from time to time to provide you tips and technical knowledge, not form, or ask questions, or discussion can and publish the answers in the day, so that we easily take advantage of debris time can learn the most practical knowledge.
2020 January 2, Thursday
[P6 class classic face questions] update SQL within the MySQL life course is like?
A, Server layer stages:
1, the connector: Responsible for establishing a connection with the client, access permissions, maintain and manage connections
2. Analyzer: after verification by, the parser will analyze the statement to determine whether there are grammatical errors
3, the optimizer: select the index, the execution plan
4, Actuator: According to the implementation plan generated by the optimizer, the storage engine API calls to execute SQL
Two, InnoDB engine layer phases:
1, transaction execution phases:After entering the InnoDB engine layer, the first page will determine whether the SQL involved exists in the cache, if there is no disk reads data from the page to the rows where BP and loaded into the buffer pool. Assuming no, then read by a B + Tree index page to disk is loaded into the buffer pool BP, BP how to load into the pool: After passing through the first page no space id and the calculated hash index is loaded into the specified page buffer pool instance is determined whether there is a free page available free list (Innodb_buffer_pool_pages_free, Innodb_buffer_pool_wait_free), without the elimination or lru list of dirty pages in the page data Old page copy to the free list, and then loaded into the midpoint old region lru list (the head ); by the dichotomy of the page to find the corresponding record, trying to give the SQL rows involved plus exclusive lock, as follows: If the line lock the current record of the transaction is occupied by other matters, then you need to enter the lock wait; lock into the after waiting, and judges will not join because of his led to deadlock; it detects no lock after waiting and will not cause a deadlock, rows plus exclusive lock. Wrote undo logic: before recording undo modify write modified values of the current line fill transaction number, a pointer to the row rollback undo log in before the rollback modified to construct, and implementation of data for rollback multiple versions of MVCC write redo log buffer: first determine whether the redo log buffer enough, redo log buffer is not enough to wait, reflected in the state value Innodb_log_waits; In Lru list BP buffer pool to do the update operation field values rows midpont old page data area, and writes the modified value after the field to redo log Buffer and add this to the redo log write LSN the length (length length of written redo log, LSN will add length) (because of the redo group commit, redo log buffer generated by the firm may follow other transactions with flush and sync to disk) field value in the buffer pool after BP successfully updated, the corresponding data page is dirty pages of written binlog cache: while the modified information, will follow the format of the event, recorded in binlog_cache. Write change buffer: when after put the sql, needs to be done in the secondary index changes written to change buffer page, wait until the next time there is need to read the other sql secondary indexes, go and do merge secondary index (random I / O into a sequential I / O, but due to the current disk is SSD, so for the addressing, the random I / O and sequential I / O gap is not) the transaction commit or rollback: At this time the update statement has been completed, we need to commit or rollback. 1 discussed herein, i.e., bis sync_binlog = 1 and innodb_flush_log_at_trx_commit = 1; At this update statement has been completed, we need to commit or rollback. 1 discussed herein, i.e., bis sync_binlog = 1 and innodb_flush_log_at_trx_commit = 1; At this update statement has been completed, we need to commit or rollback. 1 discussed herein, i.e., bis sync_binlog = 1 and innodb_flush_log_at_trx_commit = 1;
2, assuming that the transaction COMMIT
COMMIT (. 1) into the transaction prepare phase and phase commit transaction COMMIT operation, between the storage layer and the server engine is used in an internal layer XA; two-phase commit protocol to ensure consistency of the two transactions, where the main guarantee redo binlog log and the atomicity;
(2) redo log prepare: writing redo log in a prepare state and a write transaction XID; redo log Buffer will be flushed to disk redo log file, for Crash Recovery; # decided by the brush plate innodb_flush_log_at_trx_commit
(3) binlog write & fsync: Actuator the binlog Cache in the completed transaction and redo log prepare the XID written into binlog the dump thread the event sends the binlog_cache in to the slave I / O thread, while performing fsync brush disc (large transaction, then this step is very time-consuming), and empty binlog cache. # Transaction log write binlog part: 190511 11:06:54 server id 123306 end_log_pos 439 CRC32 0x1c809de0 Xid = 614COMMIT / * * /; binlog brush plate is determined by the way sync_binlog; binlog writing is completed, even if the transaction is successful!. During the transaction, first log written binlog cache, transaction commit, then binlog cache writes binlog file in. When sync_binlog is 1, the disc will fall When binlog dump thread notification from the master copy for
(4) redo log commit: commit phase, due before the transaction has generated redo log sync to the disk. So this step marks only commit the redo log in, indicating the success of the transaction commits.
(5) the transaction is committed successfully, the release of rows to hold an exclusive lock;
(6) When the binlog and redo log have been off the disk, if the trigger operation flushing dirty pages: first copy the dirty pages to doublewrite buffer, the next in the doublewrite buffer flushed to share table space (ibdata), then dirty page is written to disk; which is consistent with the disk when memory pages data page.
3, assuming that the transaction ROLLBACK If the transaction is due to abnormal or explicit rollback, then all data changes must be changed back. Here it is necessary to use the rollback log data to restore. For in-place (in situ) update, roll back data to the oldest version; to delete + insert way, the cleanup deletes records marked for deletion mark while the insert clustered index and secondary index records will be directly delete.
Third, so far, an update SQL end of the life course in MySQL