更新?user?表中?id=1?的這條數(shù)據(jù)茉继，它的大致流程如上：
●?1、客戶端連接到MySQL服務(wù)器蚀乔，將SQL更新語句發(fā)送到服務(wù)器烁竭；
MySQL服務(wù)器連接池中會(huì)有一個(gè)連接和客戶端建立連接，然后后臺(tái)線程會(huì)從連接中獲取到要執(zhí)行的SQL語句吉挣，并發(fā)送給SQL接口去調(diào)度執(zhí)行派撕。
●?2、增睬魂、刪终吼、改?時(shí)，會(huì)將查詢緩存中?user?表相關(guān)的緩存都清空汉买。
●?3、SQL語句經(jīng)過SQL解析器解析佩脊、優(yōu)化器優(yōu)化蛙粘，得到一個(gè)執(zhí)行路徑，前面這些和執(zhí)行查詢其實(shí)都是類似的威彰。
●?4出牧、接著由執(zhí)行引擎去調(diào)用底層的存儲(chǔ)引擎接口，根據(jù)執(zhí)行計(jì)劃完成SQL語句的執(zhí)行歇盼。
○?首先查詢出要更新的數(shù)據(jù)舔痕，這一步會(huì)先判斷緩沖池（Buffer?Pool）中是否已經(jīng)存在這條數(shù)據(jù)，如果已經(jīng)存在了豹缀，則直接從緩存池獲取數(shù)據(jù)返回伯复。否則從磁盤數(shù)據(jù)文件中加載這條數(shù)據(jù)到緩沖池中，再返回?cái)?shù)據(jù)邢笙。
○?獲取到數(shù)據(jù)后啸如，執(zhí)行引擎會(huì)根據(jù)SQL更新數(shù)據(jù)，然后調(diào)用存儲(chǔ)引擎更新數(shù)據(jù)氮惯。這一步會(huì)對(duì)數(shù)據(jù)加排它鎖叮雳，避免并發(fā)更新問題想暗。之后先寫?undolog?到緩沖池，undolog?主要用于事務(wù)回滾帘不、MVCC等说莫；同時(shí)，undolog?也會(huì)產(chǎn)生?redolog?日志寞焙。
○??之后更新緩沖池中的數(shù)據(jù)储狭，同時(shí)記錄?redolog?到?RedoLog緩沖池，redolog?主要用于保證數(shù)據(jù)的持久性棺弊，宕機(jī)恢復(fù)數(shù)據(jù)等晶密。
○?最后提交事務(wù)，雖然沒有手動(dòng)?commit?提交事務(wù)模她，update?語句執(zhí)行完成后也會(huì)有隱式的事務(wù)提交的稻艰。事務(wù)提交時(shí)，會(huì)先在MySQL服務(wù)器層面會(huì)寫入?binlog侈净，binlog是數(shù)據(jù)持久性的保證尊勿。最后將redolog刷入磁盤，完成事務(wù)提交畜侦。
●?5元扔、最底層的一部分就是磁盤上的數(shù)據(jù)文件、日志文件等旋膳，可以看到澎语，InnoDB?設(shè)計(jì)了緩沖池來緩沖數(shù)據(jù)、undolog验懊、redolog?等擅羞，這些內(nèi)存中的數(shù)據(jù)最終都是要刷新到磁盤中才能保證數(shù)據(jù)不丟失的。
事務(wù)特性:
○?原子性
■?指一個(gè)數(shù)據(jù)庫事務(wù)中的所有操作是不可分割的單元义图，只有事務(wù)中所有的數(shù)據(jù)庫操作都執(zhí)行成功减俏，才算整個(gè)事務(wù)成功。事務(wù)中任何一個(gè)SQL語句執(zhí)行失敗碱工，已經(jīng)執(zhí)行成功的SQL語句也必須撤銷娃承，數(shù)據(jù)庫狀態(tài)應(yīng)該退回到執(zhí)行事務(wù)前的狀態(tài)
○?一致性?
■?指事務(wù)將數(shù)據(jù)庫從一種狀態(tài)轉(zhuǎn)變?yōu)橄乱环N一致的狀態(tài)。在事務(wù)開始之前和事務(wù)結(jié)束以后怕篷，數(shù)據(jù)庫的完整性約束沒有被破壞历筝。
○?隔離性
■?也叫?并發(fā)控制、可串行化廊谓、鎖等漫谷。事務(wù)的隔離性要求每個(gè)讀寫事務(wù)的對(duì)象對(duì)其他事務(wù)的操作對(duì)象能相互分離，即該事務(wù)提交前對(duì)其他事務(wù)都不可見蹂析，通常這使用鎖來實(shí)現(xiàn)
○?持久性
■?要求事務(wù)一旦提交舔示，其結(jié)果就是永久性的碟婆。即使發(fā)生宕機(jī)等故障，數(shù)據(jù)庫也能將數(shù)據(jù)恢復(fù)
事務(wù)分類：
●?扁平事務(wù)（Flat?Transactions）
●?帶有保存點(diǎn)的扁平事務(wù)（Flat?Transactions?with?Savepoints）
●?鏈?zhǔn)聞?wù)（Chained?Transactions）
●?嵌套事務(wù)（Nested?Transactions）
●?分布式事務(wù)（Distributed?Transactions）
對(duì)于InnoDB存儲(chǔ)引擎來說惕稻，其支持扁平事務(wù)竖共、帶有保存點(diǎn)的事務(wù)、鏈?zhǔn)聞?wù)俺祠、分布式事務(wù)公给。對(duì)于嵌套事務(wù)，其并不原生支持蜘渣。
1淌铐、扁平事務(wù)
扁平事務(wù)是事務(wù)類型中最簡單的一種，也是使用最為頻繁的事務(wù)蔫缸。在扁平事務(wù)中腿准，所有操作都處于同一層次，由?BEGIN/START?TRANSACTION?開始拾碌，由?COMMIT?或?ROLLBACK?結(jié)束吐葱，其間的操作是原子的。
2校翔、帶有保存點(diǎn)的扁平事務(wù)
帶有保存點(diǎn)的扁平事務(wù)允許在事務(wù)執(zhí)行過程中回滾到同一事務(wù)中較早的一個(gè)狀態(tài)弟跑。我們可以在事務(wù)過程中設(shè)置一些保存點(diǎn)（Savepoint），保存點(diǎn)用來通知系統(tǒng)應(yīng)該記住事務(wù)當(dāng)前的狀態(tài)防症，以便當(dāng)之后發(fā)生錯(cuò)誤時(shí)孟辑，事務(wù)能回到保存點(diǎn)當(dāng)時(shí)的狀態(tài)。
對(duì)于扁平事務(wù)來說蔫敲，其在事務(wù)開始的時(shí)候隱式地設(shè)置了一個(gè)保存點(diǎn)饲嗽，扁平事務(wù)就只有這一個(gè)保存點(diǎn)，因此燕偶，回滾只能回滾到事務(wù)開始時(shí)的狀態(tài)喝噪。
可以通過?SAVEPOINT?創(chuàng)建一個(gè)保存點(diǎn)础嫡，ROLLBACK?TO?SAVEPOINT?回滾到某個(gè)保存點(diǎn)指么。
3、鏈?zhǔn)聞?wù)
鏈?zhǔn)聞?wù)就是一個(gè)事務(wù)在提交的時(shí)候自動(dòng)將上下文傳給下一個(gè)事務(wù)榴鼎，也就是說一個(gè)事務(wù)的提交和下一個(gè)事務(wù)的開始是原子性的伯诬，下一個(gè)事務(wù)可以看到上一個(gè)事務(wù)的結(jié)果，就好像在一個(gè)事務(wù)中進(jìn)行的一樣巫财。
鏈?zhǔn)聞?wù)可視為保存點(diǎn)模式的一種變種盗似，不同的是，帶有保存點(diǎn)的扁平事務(wù)能回滾到任意正確的保存點(diǎn)平项，而鏈?zhǔn)聞?wù)中的回滾僅限于當(dāng)前事務(wù)赫舒。
MySQL?的鏈?zhǔn)绞聞?wù)可以通過?SET?completion_type?=?1?打開悍及。
4、嵌套事務(wù)
嵌套事務(wù)是一個(gè)層次結(jié)構(gòu)框架接癌，由一個(gè)頂層事務(wù)控制著各個(gè)層次的事務(wù)心赶。頂層事務(wù)之下嵌套的事務(wù)被稱為子事務(wù)，其控制每一個(gè)局部的變換缺猛。子事務(wù)提交后不會(huì)真的提交缨叫，而是等到父事務(wù)提交才真正的提交，父事務(wù)回滾了荔燎，會(huì)回滾所有子事務(wù)耻姥。
MySQL?不支持嵌套事務(wù)，不過我們可以通過帶有保存點(diǎn)的事務(wù)來模擬串行的嵌套事務(wù)有咨。
5琐簇、分布式事務(wù)
分布式事務(wù)通常是一個(gè)在分布式環(huán)境下運(yùn)行的扁平事務(wù)，需要根據(jù)數(shù)據(jù)所在位置訪問網(wǎng)絡(luò)中的不同節(jié)點(diǎn)摔吏。
