A: Update Process
- For the update, it will also be based on the flow of execution of SQL.
- 
- Connector
- connect to the database, specifically the magazine.
- Query Cache
- In a there is a time to update the table , with the table-related query cache will fail.
- This is what we generally do not recommend using the query cache causes.
- analyzer
- Next, the parser will know that this is an update statement by morphology and syntax parsing.
- optimizer
- optimizer decides to use the ID of the index.
- Actuator
- Then, is responsible for the specific implementation, find this line, and then update.
- PS
- the query process is not the same, the update process also involves two important log module, the protagonist of which is exactly what we want to talk about today:
- redo log (redo logs) and binlog (archive log) .
二： redo log
- Mysql update problems
- In MySQL, if each record update , you need to write to the disk .
- then you have to find that record corresponding to the disk, and then update the whole process IO costs, find costs are high .
- To solve this problem, MySQL designers to use the concept of redo log to solve this problem.
- redo log Overview
- redo log InnoDB is unique , belonging to the storage engine layer of
- redo log Workflow
- In particular, when there is a record update time, InnoDB engine will first record written to redo log inside , and update the memory , this time to update even completed .
- At the same time, InnoDB will in due course , this operation will record updates to disk inside.
- PS
- InnoDB redo log is of a fixed size
- for example can be configured as a set of four files, each file is 1GB, then the recording operation can be a total of 4GB.
- written from scratch, it is written to the end back to the beginning of the write cycle
- When the redo log is filled with time, this time not in the implementation of the new update, you must stop and erase some of the redo log log is written to disk
- With the redo log , InnoDB can guarantee reboots occur even if the database records before you submit will not be lost , this ability is called crash-safe
Three: binlog
- binlog Overview
- binlog (archive log) is a layer-specific Server
- Why are there two log?
- Since the beginning there has not MySQL InnoDB engine.
- MySQL's own engine is MyISAM, but can not afford to crash-safe MyISAM is, binlog log can only be used for archiving.
- The introduction of MySQL InnoDB is another company in the form of plug-ins, since only rely on binlog is not crash-safe capability
- So InnoDB uses another set of logging system - that is, redo log to achieve the crash-safe capability.
Four: different binlog and the redo log
- redo log InnoDB engine is unique; binlog is the MySQL Server layer implementation, all engines can be used.
- redo log is a physical log record is " on a data page change has been made ."
- the binlog is logical log , records the original logic of the sentence, such as "to field ID = c 2 of this line plus one."
- redo log is written cycle, spatially fixed run out;
- binlog can be added to writes . "Additional write" refers to the binlog file written to a certain size will switch to the next and does not overwrite the previous log.
Five: Look execution process Update
- E.g
- mysql> update T set c=c+1 where ID=2;
- Process
- actuators find someone to take the engine ID = 2 this line .
- ID is the primary key, the search engine directly with tree Find the line.
- the data page ID = 2, if the line is already located in memory, it is returned directly to the actuator
- Otherwise, you need to start disk into memory, and back again.
- row data engine to get the actuator
- this value plus 1, for example, turned out to be N, now is the N + 1, to obtain a new line of data, and then write this line engine interface calls the new data.
- engine this line updated with new data into memory
- while the update operation to redo log record which, in this case redo log prepare state.
- then told Actuators completed, ready to commit the transaction.
- the implementation of this operation generates binlog , and the binlog written to disk.
- execution engine call to commit the transaction interfaces, the engine just written redo log into submission (commit) state , the update is complete.
- 
Six: redo of "two-phase commit"
- a flow chart above, you can see, redo log write split into two steps: prepare and commit, this is the "two-phase commit."
- the reason
- Since the redo log and are two separate logical binlog
- If you do not have two-phase commit, or is asked to finish redo log write binlog, or vice versa using the order would result in inconsistent data appears.
- Simply put, redo log and binlog can be used to represent the state of affairs of the submission, and the two-phase commit is to make the two state consistent logic.
- example of a complete transaction process
- 账本记上 卖一瓶可乐（redo log为 prepare状态），然后收钱放入钱箱（bin log记录）然后回过头在账本上打个勾（redo log置为commit）表示一笔交易结束。
- 如果收钱时交易被打断，回过头来整理此次交易，发现只有记账没有收钱，则交易失败，删掉账本上的记录（回滚）
- 如果收了钱后被终止，然后回过头发现账本有记录（prepare）而且钱箱有本次收入（bin log），则继续完善账本（commit），本次交易有效。
七：小结
- redo log 用于保证 crash-safe 能力。
- innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。
- 这个参数建议设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
- sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。
- 这个参数也建议设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。
- 还介绍了与 MySQL 日志系统密切相关的“两阶段提交”。
- 两阶段提交是跨系统维持数据逻辑一致性时常用的一个方案，即使你不做数据库内核开发，日常开发中也有可能会用到。