6 鎖

數(shù)據(jù)庫(kù)區(qū)別與文件系統(tǒng)的一個(gè)關(guān)鍵特性

6.1 什么是鎖

鎖機(jī)制用于管理對(duì)共享資源的并發(fā)訪問。

Innodb引擎不僅僅是在行級(jí)別上使用鎖，在其他方面也會(huì)使用。例如：操作緩沖池中的LRU列表，刪除、添加、移動(dòng)LRU列表中的元素

6.2 InnoDB存儲(chǔ)引擎中的鎖

6.2.1 鎖類型

兩種標(biāo)準(zhǔn)的行級(jí)鎖：

共享鎖(S lock)：允許事務(wù)讀一行數(shù)據(jù)

排他鎖(X lock)：允許事務(wù)刪除或更新一行數(shù)據(jù)

為了支持在不同粒度上進(jìn)行加鎖操作，Innodb 引擎支持意象鎖(Intention Lock)，意象鎖是將鎖定的對(duì)象分為多個(gè)層次，意象鎖意味著事務(wù)希望在更細(xì)粒度上進(jìn)行加鎖。(不會(huì)阻塞除全表掃描之外的其他任何請(qǐng)求)

在InnoDB Plugin之前，只能通過SHOW FULL PROCESSLIST、SHOW ENGINE INNODB STATUS等命令來查看當(dāng)前的數(shù)據(jù)庫(kù)請(qǐng)求，然后在判斷當(dāng)前事務(wù)中鎖的情況。

新版本中在INFORMATION_SCHEMA架構(gòu)下添加了INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS三張表。通過這三張表可以簡(jiǎn)單的監(jiān)控當(dāng)前的事務(wù)并分析鎖的問題。

Mysql8.0 將 information_schema.innodb_locks改為 performance_schema.data_locks

INNODB_TRX字段

• trx_id：事務(wù)id
• Trx_state：當(dāng)前事務(wù)的狀態(tài)
• trx_started: 事務(wù)開啟時(shí)間
• trx_requested_lock_id：等待事務(wù)的鎖ID
• trx_wait_started:事務(wù)等待開始的時(shí)間
• trx_weight:事務(wù)權(quán)重，反應(yīng)了一個(gè)事務(wù)修改和鎖住的行數(shù)
• trx_mysql_thread_id： mysql中的線程ID，show processlist 顯示的結(jié)果
• trx_query: 事務(wù)運(yùn)行的sql，實(shí)際中有時(shí)會(huì)顯示null

INNODB_LOCKS的字段

• lock_id：鎖的id
• lock_trx_id：事務(wù)的id
• lock_mode：鎖的模式
• lock_type：鎖的類型，行鎖或者是表鎖
• lock_table：要枷鎖的表
• lock_space：Innodb引擎表空間的id
• lock_page：被鎖住的頁(yè)的數(shù)量，若為表鎖，則為null
• lock_rec：被鎖主的行的數(shù)量，若為表鎖，澤偉null
• lock_data：被鎖住行的主鍵，歐維表鎖，則為null

INNODB_LOCK_WAITS的字段

• requesting_trx_id：申請(qǐng)鎖資源的事務(wù)id
• requesting_lock_id：申請(qǐng)的鎖的id
• block_trx_id：阻塞的事務(wù)id
• block_lock_id：阻塞的鎖的id

6.2.2 一致性的非鎖定讀操作

非鎖定讀大大提高了讀取的并發(fā)性，是Innodb引擎中默認(rèn)的讀取方式，即讀取不會(huì)占用和等待表上的鎖。

一致性的非鎖定讀(consistent nonlocking read)是指InnoDB引擎通過多版本控制(multi versioning)的方式來讀取當(dāng)前執(zhí)行時(shí)間數(shù)據(jù)庫(kù)中的數(shù)據(jù)。如果讀取的數(shù)據(jù)正在執(zhí)行DELETE、UPDATE操作，這是操作并不會(huì)等待鎖的釋放，而是會(huì)去讀取行的一個(gè)快照數(shù)據(jù)。

上圖展示了Innodb引擎的一致性非鎖定讀(不需要等待X鎖的釋放)。快照數(shù)據(jù)是指該行數(shù)據(jù)之前版本的數(shù)據(jù)，該實(shí)現(xiàn)是通過Undo段實(shí)現(xiàn)的。而Undo用來在事務(wù)回滾數(shù)據(jù)，因此快照數(shù)據(jù)本身沒有額外的開銷(此外讀取快照數(shù)據(jù)不需要上鎖)

• 注意：

  在不同事務(wù)隔離級(jí)別下，讀取的方式不同，并不是每個(gè)事務(wù)隔離級(jí)別下讀取的都是一致性讀。

  在上圖得知，快照數(shù)據(jù)并不是只有一個(gè)版本，一個(gè)行可能有不止一個(gè)快照數(shù)據(jù)(多版本技術(shù))。由此帶來的并發(fā)控制稱為多版本并發(fā)控制(Multi Version Concurrency Control, MVCC)。

  • Read Committed

    在讀已提交事務(wù)隔離級(jí)別下，對(duì)于快照數(shù)據(jù)，總是讀取被鎖定行的最新的一份快照數(shù)據(jù)。

  • Repeatable Read (innodb 引擎的默認(rèn)隔離級(jí)別)

    在可重復(fù)度事務(wù)隔離級(jí)別下，對(duì)于快照數(shù)據(jù)，總是讀取事務(wù)開始時(shí)行的快照數(shù)據(jù)

  上述情況的例子：

  -- 回話A： begin; -- 開啟事務(wù) select * from table where id = 1; -- 此時(shí)查出id=1的數(shù)據(jù) (沒有提交事務(wù))-- 會(huì)話B：(此時(shí)A沒有結(jié)束事務(wù)) begin; update table set id = 3 where id = 1; -- 將id改為3 (事務(wù)同樣沒有提交)

  經(jīng)過上述步驟，此時(shí)的會(huì)話B給行加了一個(gè)X鎖， 如果此時(shí)再次回到會(huì)話A中讀取數(shù)據(jù)，根據(jù)Innodb引擎的特性，在Read Committed和Repeatable Read事務(wù)隔離級(jí)別下使用非鎖定一致性讀。

  在上述兩個(gè)隔離級(jí)別下，會(huì)話A中仍然能夠查到id為1的數(shù)據(jù)(因?yàn)榇藭r(shí)只有一份快照數(shù)據(jù)，因此不管哪個(gè)事務(wù)隔離級(jí)別，結(jié)果都一樣)。

  然后回到會(huì)話B中，執(zhí)行commit，提交事務(wù)，然后在回到會(huì)話A中，執(zhí)行查詢，此時(shí)兩種隔離級(jí)別的查詢結(jié)構(gòu)就不同了，

  對(duì)于 ReadCommitted 事務(wù)隔離級(jí)別來說，他總是讀取行的最新版本，如果行被鎖定了，則讀取該行版本的最新的一個(gè)快照(fresh snapshot)。在上述情況下，會(huì)話 B 已經(jīng)提交，所以 Read Committed事務(wù)隔離級(jí)別下，執(zhí)行 sql select * from table where id = 1是查不到數(shù)據(jù)的

  對(duì)于 Repeatable Read事務(wù)隔離級(jí)別，總是讀取事務(wù)開始的行數(shù)據(jù)，因此執(zhí)行 sqlselect * from table where id = 1仍然可以查到 id 為1的數(shù)據(jù)。

  -- 查詢當(dāng)前事務(wù)隔離級(jí)別select @@tx_isolation;

  對(duì)于 Read Committed事務(wù)隔離級(jí)別來說，其實(shí)是違背了事務(wù)的 ACID 中的 I特性(隔離性)

6.2.3 SELECT .. FOR UPDATE & SELECT ... LOCK IN SHARE MODE

在上邊說過，默認(rèn)情況下，innodb 引擎的 select 操作使用一致性非鎖定讀。 但在某些情況下，需要對(duì)讀進(jìn)行加鎖操作。

讀加鎖操作的兩種方式：

SELECT ... FOR UPDATE

對(duì)讀的行記錄加一個(gè) X 鎖(排它鎖)，其他事務(wù)想在這些行上加任何鎖都會(huì)被阻塞

對(duì)于一致性非鎖定讀，此時(shí)讓然可以進(jìn)行讀取

SELECT ... LOCK IN SHARE MODE

對(duì)讀取操作加一個(gè) S 鎖(共享鎖)，其他事務(wù)可以向被鎖定的行加 S 鎖，但是 對(duì)于X 鎖，會(huì)被阻塞

另外，上述兩種方式，必須在一個(gè)事務(wù)中，當(dāng)事務(wù)提交了，鎖也就失效了(因?yàn)樵谑褂蒙线厓蓚€(gè)語(yǔ)句時(shí)，是要加上 BEGIN、START TRANSACTION、SET AUTOCOMMIT=0)

6.2.4 自增長(zhǎng)和鎖

對(duì)于含有自增長(zhǎng)值的表都有一個(gè)自增長(zhǎng)計(jì)數(shù)器(auto-increment counter)。當(dāng)插入時(shí)，這個(gè)計(jì)數(shù)器會(huì)被初始化，執(zhí)行以下 sql 來獲取值：

select MAX(auto_inc_col) from t for update;

插入操作會(huì)根據(jù)這個(gè)值加1給自增長(zhǎng)列。即 AUTO-INC Locking，這種鎖定機(jī)制其實(shí)是一種表鎖機(jī)制，為了提高性能，鎖不是在一個(gè)事務(wù)完成之后才釋放，而是在完成對(duì)自增長(zhǎng)值的插入后立即釋放。(這種方式對(duì)于大批量數(shù)據(jù)會(huì)影響效率)

在 mysql5.1.22版本開始，提供了一種輕量級(jí)互斥量的自增長(zhǎng)實(shí)現(xiàn)機(jī)制，參數(shù) innodb_autoinc_lock_mode默認(rèn)值為1。(不同的參數(shù)對(duì)于不同的插入有不同的影響)

插入方式分類：

INSERT-like：指所有的插入語(yǔ)句，例如 INSERT、REPLACT、INSERT ... SELECT、REPLACE ... SELECT、LOAD DATA等

Simple inserts：指在插入之前就能確定插入的行數(shù)，如：INSERT、REPLACE，不包括INSERT ...ON DUPLICATE KEY REPLACE

Bulk inserts：指插入之前不能確定行數(shù)，如INSERT ... SELECT、REPLACE ... SELECT、LOAD DATA

Mixed-mode inserts：指插入數(shù)據(jù)有一部分指是自增長(zhǎng)的，有一部分指是確定的，如：INSERT INTO t1(c1,c2)VALUES (1,'A'),(NULL,'B'),(4,'C'),(NULL,'D');也可以指INSERT ...ON DUPLICATE KEY REPLACE這類 sql

innodb_autoinc_lock_mode有3個(gè)可選指：

0，mysql5.1.22版本之前的自增長(zhǎng)實(shí)現(xiàn)方式

1，默認(rèn)值，對(duì)于 Simple inserts 會(huì)使用互斥量產(chǎn)生自增長(zhǎng)值，對(duì)于 Bulk Inserts 仍然使用 AUTO-INC Locking 的方式

2，對(duì)于所有的 INSERT-like 自增長(zhǎng)值的產(chǎn)生都是通過互斥量，而不是 AUTO-INC Locking (性能最高的方式)

innodb_autoinc_lock_mode=2，會(huì)有兩個(gè)問題：一是并發(fā)插入，會(huì)導(dǎo)致自增長(zhǎng)值不是連續(xù)的，二是，對(duì)于基于 Statement-Base Replication 的復(fù)制會(huì)出現(xiàn)問題(Row-Base Replication 沒問題)

6.2.5 外鍵和鎖

6.3 鎖的算法

Innodb 引擎有3中行鎖：

Record Lock： 單個(gè)行記錄上的鎖(總是會(huì)去鎖定索引的，如果沒有索引，Innodb 引擎會(huì)使用隱式的主鍵來進(jìn)行鎖定)

Gap Lock： 間隙鎖，鎖定一個(gè)范圍，但是不包括記錄本身

Next-Key Lock：Gap Lock + Record Lock， 鎖定一個(gè)范圍，包括記錄(Innodb 引擎對(duì)于行的查詢都是基于這種算法，對(duì)于不同 sql 查詢語(yǔ)句，可能設(shè)置共享Next-Key Lock 和排他的 Next-Key Lock) -- 解決了幻讀問題

例子：

begin; select * from t where id < 5 lock in share mode; -- 在上述 情況下執(zhí)行 insert into t (id) values(3); -- 此時(shí)插入語(yǔ)句會(huì)阻塞 -- 因?yàn)樵?Next-Key Locking 算法下，鎖定的是 id < 6的所有值，但是如果插入 id=9，是可以的-- 如果是查詢指定 id 的值，是不會(huì)影響其他數(shù)據(jù)的插入的，因?yàn)?innodb 引擎會(huì)選擇一個(gè)最小的算法模型

6.4 鎖問題

丟失更新

臟讀

不可重復(fù)讀

6.4.1 丟失更新

兩個(gè)查詢，分別顯示到兩個(gè)頁(yè)面，兩個(gè)分別更新，第二次更新會(huì)直接覆蓋第一次更新，導(dǎo)致了第一次更新丟失

解決：數(shù)據(jù)上加版本號(hào)，更新時(shí)對(duì)比版本號(hào)

6.4.2 臟讀

是指讀到了未提交的數(shù)據(jù)(這種情況只會(huì)發(fā)生在事務(wù)隔離級(jí)別設(shè)置為 Read Uncommitted的情況下)

6.4.3 不可重復(fù)讀

多次讀到的數(shù)據(jù)不同，發(fā)生在事務(wù)隔離級(jí)別為 Read Committed的情況下，違反了隔離性

不可重復(fù)讀的問題是可以接受的，因此像 oracle、microsoft sql sever 的隔離級(jí)別都是讀已提交

mysql 通過 Next-key Lock算法來避免不可重復(fù)讀

6.5 阻塞

Innodb 引擎中，通過參數(shù) innodb_lock_wait_timeout 來控制等待的時(shí)間(默認(rèn)50秒)，innodb_rollback_on_timeout用來設(shè)定是否在等待超時(shí)時(shí)對(duì)事物進(jìn)行回滾操作(默認(rèn)為 OFF，代表不回滾)

6.6 死鎖

Innodb 存儲(chǔ)引擎并不會(huì)回滾大部分的異常，但是死鎖除外，當(dāng)發(fā)生死鎖時(shí)，Innodb 會(huì)馬上回滾一個(gè)事務(wù)

6.7 鎖升級(jí)

鎖升級(jí)(Lock Escalation)是指將當(dāng)前鎖的粒度降低。例如：數(shù)據(jù)庫(kù)可以把一個(gè)表的1000個(gè)行鎖升級(jí)為一個(gè)頁(yè)鎖，或者將頁(yè)鎖升級(jí)為表鎖。

Innodb 存儲(chǔ)引擎中不存在鎖升級(jí)的問題，1個(gè)鎖和10000個(gè)鎖時(shí)一樣的，沒有開銷

7 事務(wù)

用來保證數(shù)據(jù)的完整性

分類：

扁平事務(wù)(Flat Transaction)

是事務(wù)類型中最簡(jiǎn)單的一種，但是實(shí)際生產(chǎn)環(huán)境中使用最頻繁，即其間操作都是原子的，要么都執(zhí)行，要么都回滾。因此扁平事務(wù)是應(yīng)用程序稱為原子操作的基本組成模塊。

扁平事務(wù)的主要限制是不能提交或回滾事務(wù)的某一部分，或分成幾個(gè)步驟提交。

帶有保存點(diǎn)的扁平事務(wù)(Flat Transaction with savepoints)

除了支持扁平事務(wù)支持的操作外，允許在事務(wù)執(zhí)行的過程中回滾到同一事務(wù)中較早的一個(gè)狀態(tài)。這是因?yàn)槟承┦聞?wù)可能執(zhí)行過程中出現(xiàn)的錯(cuò)誤并不會(huì)導(dǎo)致所有的操作都無效，放棄整個(gè)事務(wù)不合乎要求。

保存點(diǎn)(savepoint)用來同值系統(tǒng)應(yīng)該記住事務(wù)當(dāng)前的狀態(tài)，以便事務(wù)發(fā)生錯(cuò)誤時(shí)，事務(wù)能回到保存點(diǎn)當(dāng)時(shí)的狀態(tài)。

鏈?zhǔn)绞聞?wù)(Chained Transactions)

可視為保存點(diǎn)模式的一個(gè)變種。其區(qū)別是，帶有保存點(diǎn)的扁平事務(wù)能回滾到任意正確的保存點(diǎn)。而鏈?zhǔn)绞聞?wù)中回滾僅限于道歉事務(wù)。

嵌套事務(wù)(Nested Transactions)

是一種層次結(jié)構(gòu)框架。由一個(gè)頂層事務(wù)控制著各個(gè)層次的事務(wù)。頂層事務(wù)之下嵌套的事務(wù)被稱為漬食物，其控制每一個(gè)局部的變換。

分布式事務(wù)(Distributed Transactions)

innodb引擎支持扁平事務(wù)，帶有保存點(diǎn)的扁平事務(wù)。鏈?zhǔn)绞聞?wù)。分布式事務(wù)。

7.1 概述

事務(wù)的特性：ACID

原子性(atomicity)

指整個(gè)數(shù)據(jù)庫(kù)事務(wù)是不可分割的單位。只有所有的數(shù)據(jù)庫(kù)操作都執(zhí)行成功才算成功。

一致性(consistency)

指事務(wù)將數(shù)據(jù)庫(kù)從一種狀態(tài)轉(zhuǎn)變?yōu)橄乱环N一致性的狀態(tài)，在事務(wù)開始和結(jié)束以后，數(shù)據(jù)庫(kù)的完整性約束沒有破壞

隔離性(isolation)

一個(gè)事務(wù)的影響在該事務(wù)提交前對(duì)其他事務(wù)不可見--通過鎖實(shí)現(xiàn)的

持久性(durability)

事務(wù)一旦提交，其結(jié)果就是永久性的

另事務(wù)的隔離級(jí)別：

讀未提交

讀已提交

可重復(fù)讀

序列化讀

7.2 事務(wù)的實(shí)現(xiàn)

隔離性通過鎖來實(shí)現(xiàn)

原子性、一致性、持久性通過數(shù)據(jù)庫(kù)的 redo 和 undo 來完成

原子性、持久性 ---> redo

持久性 ----> undo

7.2.1 redo

重做日志用來實(shí)現(xiàn)事務(wù)的持久性，即事務(wù)ACID中的D。由兩部分組成，一是內(nèi)存中的重做日志緩沖(redo log buffer)，其實(shí)易失的。二是重做日志文件(redo log file)，其實(shí)持久的。

當(dāng)開始一個(gè)事務(wù)時(shí)，會(huì)記錄該事務(wù)的一個(gè) LSN(Log Sequence Number，日志序列號(hào))，當(dāng)事務(wù)執(zhí)行時(shí)，會(huì)往 Innodb 引擎的日志緩沖里插入事務(wù)日志；當(dāng)事務(wù)提交時(shí)，必須將 InnoDB 引擎的日志緩沖寫入磁盤。也就是在寫數(shù)據(jù)前，需要先寫日志(預(yù)寫日志方式 Write-Ahead Logging, WAL)

在innodb引擎中，重做日志都是以512字節(jié)進(jìn)行存儲(chǔ)的。這意味著重做日志緩存、重做日志文件都是以塊(block)的方式保存的，也就是重做日志塊(redo log block)，每塊為512字節(jié)。

若一個(gè)頁(yè)中產(chǎn)生的重做日志數(shù)量大于512字節(jié)，那么需要分割為多個(gè)重做日志塊及逆行存儲(chǔ)。此外，由于重做日志塊的大小和扇區(qū)大小一樣，都是512字節(jié)，因此重做日志的寫入可以保證原子性，不需要doublewrite技術(shù)。

重做日志文件中存儲(chǔ)的就是log buffer中保存的log block，因此其也是根據(jù)塊的方式進(jìn)行物理存儲(chǔ)的管理，每個(gè)塊的大小與log block一樣，為512字節(jié)。在innodb引擎運(yùn)行過程中，log buffer根據(jù)一定的規(guī)則將內(nèi)存中的log block刷新到磁盤：1. 事務(wù)提交時(shí) 2. 當(dāng)log buffer中有一般的內(nèi)存空間已經(jīng)被使用時(shí) 3. log checkpoint 時(shí)

對(duì)于log block的寫入追加在redo log file的最后部分，當(dāng)一個(gè)redo log file寫滿時(shí)，會(huì)接著寫入下一個(gè)redo log file。

雖然log block的寫入追加在redo log file的最后部分，但是log buffer刷新到磁盤是并不是順序地，因?yàn)樵谒⑿率?#xff0c;會(huì)刷新redo log file前2KB的信息。

LSN是log sequence Number的縮寫，代表日志序列號(hào)。在Innodb引擎中占用8字節(jié)。含義有：

重做日志寫入的總量

checkpoint的位置

頁(yè)的版本

LSN不僅記錄在重做日志中，還存在與每個(gè)頁(yè)中。在每個(gè)頁(yè)的頭部，有一個(gè)值FIL_PAGE_LSN，記錄了該頁(yè)的LSN。

7.2.2 undo

重做日志記錄了事務(wù)的行為，可以很好地通過其進(jìn)行重做，但是事務(wù)還需要撤銷(undo)。

undo 和 redo 正好相反，對(duì)數(shù)據(jù)庫(kù)進(jìn)行修改時(shí)，不但會(huì)產(chǎn)生 redo，還會(huì)產(chǎn)生一定的 undo。

和 redo不同，redo 存放在重做日志文件中，undo 存放在數(shù)據(jù)庫(kù)內(nèi)部的一個(gè)特殊段(segment)中，也就是 undo 段，該段位于共享表空間內(nèi)。(從innodb1.2版本開始可以指定獨(dú)立的表空間) (innodb_undo_directiry/ innodb_undo_logs / innodb_undo_tablespaces)

邏輯的將數(shù)據(jù)恢復(fù)到之前的樣子，例如：對(duì)于每個(gè) INSERT，存儲(chǔ)引擎回滾時(shí)會(huì)執(zhí)行 DELETE，對(duì)于 DELETE，回執(zhí)行 INSERT，對(duì)于 UPDATE，會(huì)執(zhí)行相反的 UPDATE。

除了回滾操作外，undo另一個(gè)作用是MVCC。

undo log會(huì)產(chǎn)生redo log，也就是undo log的產(chǎn)生會(huì)伴隨著redo log的產(chǎn)生，這時(shí)因?yàn)閡ndo log也需要持久性的保護(hù)。

7.3 事務(wù)控制語(yǔ)句

默認(rèn)事務(wù)都是自動(dòng)提交的

手動(dòng)開始事務(wù)的3中方式：

BEGIN

START TRANSACTION

SET AUTOCOMMIT=0

BEGIN、START TRANSACTION ，當(dāng)執(zhí)行這倆個(gè)時(shí)，mysql 會(huì)自動(dòng)執(zhí)行 SET AUTOCOMMIT=0(在默認(rèn)配置下)，當(dāng)執(zhí)行 COMMIT或者 ROLLBACK 時(shí)，會(huì)自動(dòng)執(zhí)行 SET AUTOCOMMIT=1

事務(wù)控制語(yǔ)句：

START TRANSACTION | BEGIN：顯示開啟一個(gè)事務(wù)

COMMIT：提交事務(wù)

ROLLBACK：回滾

SAVEPOINT identifier：在事務(wù)中創(chuàng)建一個(gè)保存點(diǎn)(可以有多個(gè))

RELEASE SAVEPOINT identifier：刪除一個(gè)事務(wù)的保存點(diǎn)(當(dāng)沒有保存點(diǎn)時(shí)，會(huì)跑出異常)

ROLLBACK TO [SAVEPOINT] identifier：和 SAVEPOINT 命令一起使用，可以把事務(wù)回滾到標(biāo)記點(diǎn)，而標(biāo)記點(diǎn)之前的事務(wù)不回滾

SET TRANSACTION：設(shè)置事務(wù)的隔離級(jí)別(READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE)

7.4 隱式提交的 sql

當(dāng)執(zhí)行完這些sql 后，會(huì)有一個(gè)隱式的 COMMIT 操作(即執(zhí)行這些操作后，不能回滾)：

• DDL 語(yǔ)句(包括 alter、create、drop、rename、truncate) (注意delete 不是 DDL，因此可以回滾)
• 用來隱式的修改 mysql 架構(gòu)的操作：CREATE USER 、DROP USER、GRANT、RENAME USER、REVOKE、SET PASSWORD
• 管理語(yǔ)句：ANALYZE TABLE、CACHE INDEX、CHECK TABLE、LOAD INDEX INTO CACHE、OPTIMIZE TABLE、REPAIR TABLE

7.5 對(duì)于事務(wù)的統(tǒng)計(jì)操作

每秒請(qǐng)求數(shù)(Question Per Second，QPS)、每秒事務(wù)處理能力(Transaction Per Second，TPS)

TPS=(com_commit + com_rollback) / time

7.7 分布式事務(wù)

Innodb 存儲(chǔ)引擎支持 XA 事務(wù)，通過 XA 事務(wù)可以實(shí)現(xiàn)分布式事務(wù)。

分布式事務(wù)是指允許多個(gè)獨(dú)立的事務(wù)資源(transactional resources)參與一個(gè)全局事務(wù)。

在使用分布式事務(wù)時(shí)，Innodb 存儲(chǔ)引擎的事務(wù)隔離級(jí)別必須設(shè)置為 SERIALIABLE

分布式事務(wù)由一個(gè)或者多個(gè)資源管理器(Resource Managers)、一個(gè)事務(wù)管理器(Transaction Manager)以及一個(gè)應(yīng)用程序(Application Program)組成。

分布式事務(wù)才有兩階段提交(tow-phase commit)的方式，在第一階段，所有參數(shù)全局事務(wù)的節(jié)點(diǎn)都開始準(zhǔn)備(PREPARE)，告訴事務(wù)管理器他們準(zhǔn)備好了，第二階段，事務(wù)管理器告訴資源管理器執(zhí)行 ROLLBACK 還是 COMMIT，如果任何一個(gè)節(jié)點(diǎn)顯示不能提交，則所有節(jié)點(diǎn)都要回滾。

總結(jié)

以上是生活随笔為你收集整理的mysql ---- innodb-3-锁、事务的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。