當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

性能优化专题 - MySql 性能优化 - 03 - 深入理解InnoDB

發(fā)布時(shí)間：2023/12/20 编程问答 46 豆豆

生活随笔收集整理的這篇文章主要介紹了性能优化专题 - MySql 性能优化 - 03 - 深入理解InnoDB 小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

目錄導(dǎo)航

- 前言
- MySql事務(wù)
- - 事務(wù)
  - mysql中如何開(kāi)啟事務(wù)
  - 事務(wù)的ACID特性
  - 事務(wù)并發(fā)帶來(lái)了哪些問(wèn)題
  - - 臟讀(dirty read)
    - 不可重復(fù)讀(nonrepeatableread)
    - 幻讀(Phantom read)
  - 事務(wù)四種隔離級(jí)別
  - - 四種隔離級(jí)別
    - Innodb引擎對(duì)隔離級(jí)別的支持程度
- MySql鎖
- - 理解表鎖、行鎖
  - MySQL Innodb鎖類(lèi)型
  - 共享鎖（Share Locks）vs 排它鎖（Exclusive Locks）
  - Innodb到底鎖了什么？
  - 意向共享鎖（IS）& 意向排他鎖
  - 自增鎖 AUTO-INC Locks
  - 臨鍵鎖（Next-key）&間隙鎖（Gap）&記錄鎖（Record）
  - - 臨鍵鎖（Next-key）
    - 間隙鎖（Gap）
    - 記錄鎖（Record）
  - 怎么利用鎖解決臟讀、不可重復(fù)讀、幻讀
  - 死鎖介紹
  - 死鎖如何避免
- MVCC
- - MySQL中MVCC邏輯流程
  - - 插入
    - 刪除
    - 修改
    - 查詢
  - MySQL中版本控制案例
  - - 案例一（1，2，3，4，2）
    - 案例二（3、4、1、2）
- 寫(xiě)在最后

前言

性能優(yōu)化專(zhuān)題共計(jì)四個(gè)部分，分別是：

Tomcat 性能優(yōu)化
MySql 性能優(yōu)化
JVM 性能優(yōu)化
性能測(cè)試

本節(jié)是性能優(yōu)化專(zhuān)題第二部分 —— MySql 性能優(yōu)化篇，共計(jì)四個(gè)小節(jié)，分別是：

MySql索引機(jī)制

MySql運(yùn)行機(jī)理

深入理解InnoDB

MySql調(diào)優(yōu)

MySql事務(wù)

數(shù)據(jù)庫(kù)事務(wù)(Database Transaction) ，是指作為單個(gè)邏輯工作單元執(zhí)行的一系列操作，要么完全地執(zhí)行，要么完全地不執(zhí)行。

? 事務(wù)的ACID特性，事務(wù)并發(fā)帶來(lái)了哪些特性，事務(wù)的四種隔離級(jí)別。

事務(wù)

事務(wù)（Transaction），一般是指要做的或所做的事情。在計(jì)算機(jī)術(shù)語(yǔ)中是指訪問(wèn)并可能更新數(shù)據(jù)庫(kù)中各種數(shù)據(jù)項(xiàng)的一個(gè)程序執(zhí)行單元(unit)。

數(shù)據(jù)庫(kù)事務(wù)(Database Transaction) ，是指作為單個(gè)邏輯工作單元執(zhí)行的一系列操作，要么完全地執(zhí)行，要么完全地不執(zhí)行。

典型事務(wù)場(chǎng)景(轉(zhuǎn)賬)：

update user_account set balance = balance - 1000 where userID = 3; update user_account set balance = balance +1000 where userID = 1;

mysql中如何開(kāi)啟事務(wù)

SQL編程

手工

begin / start transaction # 開(kāi)啟事務(wù) commit / rollback # 事務(wù)提交或回滾

自動(dòng)

set session autocommit = on/off; # 設(shè)定事務(wù)是否自動(dòng)開(kāi)啟

JDBC 編程

connection.setAutoCommit（boolean）;

Spring 事務(wù)AOP編程

expression=execution（com.xxx.service.*.*(..)）

事務(wù)的ACID特性

原子性（Atomicity）

? 整個(gè)事務(wù)中的所有操作，要么全部完成，要么全部不完成，不可能停滯在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過(guò)程中發(fā)生錯(cuò)誤，會(huì)被回滾（Rollback）到事務(wù)開(kāi)始前的狀態(tài)，就像這個(gè)事務(wù)從來(lái)沒(méi)有執(zhí)行過(guò)一樣。

一致性（Consistency）

? 一個(gè)事務(wù)可以封裝狀態(tài)改變（除非它是一個(gè)只讀的）。事務(wù)必須始終保持系統(tǒng)處于一致的狀態(tài)，不管在任何給定的時(shí)間并發(fā)事務(wù)有多少。

? 也就是說(shuō)：如果事務(wù)是并發(fā)多個(gè)，系統(tǒng)也必須如同串行事務(wù)一樣操作。其主要特征是保護(hù)性和不變性(Preserving an Invariant)，以轉(zhuǎn)賬案例為例，假設(shè)有五個(gè)賬戶，每個(gè)賬戶余額是100元，那么五個(gè)賬戶總額是500元，如果在這個(gè)5個(gè)賬戶之間同時(shí)發(fā)生多個(gè)轉(zhuǎn)賬，無(wú)論并發(fā)多少個(gè)，比如在A與B賬戶之間轉(zhuǎn)賬5元，在C與D賬戶之間轉(zhuǎn)賬10元，在B與E之間轉(zhuǎn)賬15元，五個(gè)賬戶總額也應(yīng)該還是500元，這就是保護(hù)性和不變性。

隔離性（Isolation）

一個(gè)事務(wù)所操作的數(shù)據(jù)在提交之前，對(duì)其他事務(wù)的可見(jiàn)性設(shè)定（一般設(shè)定為不可見(jiàn)）

持久性（Durability）

事務(wù)所做的修改就會(huì)永久保存，不會(huì)因?yàn)橄到y(tǒng)意外導(dǎo)致數(shù)據(jù)的丟失

事務(wù)并發(fā)帶來(lái)了哪些問(wèn)題

如下圖，事務(wù)A和事務(wù)B 同時(shí)操作id為1的user

臟讀(dirty read)

事務(wù)B 修改id為1的用戶age由16 --> 18

事務(wù)A 查詢id為1的用戶，獲取到age為18

事務(wù)B 此時(shí)因?yàn)槟承┮馔庠?#xff0c;rollback

（要理解1和3為同一個(gè)事務(wù)（最小執(zhí)行單元））
此時(shí)數(shù)據(jù)庫(kù)中的id為1的記錄age還是16,而事務(wù)B并不之情，以為age是18，此時(shí)就出問(wèn)題了，所謂的臟讀

不可重復(fù)讀(nonrepeatableread)

事務(wù)A 查詢id為1的用戶，獲取到age為16

事務(wù)B 修改id為1的用戶，age由16 --> 18

事務(wù)B commit

事務(wù)A 查詢id為1的用戶，獲取到age為18

（1和4一個(gè)事務(wù) 2和3一個(gè)事務(wù)，要理解成不可分割的最小執(zhí)行單元）
此時(shí)事務(wù)A兩次查詢不一樣，在一個(gè)事務(wù)重復(fù)讀數(shù)據(jù)內(nèi)容不一樣，所謂的不可重復(fù)讀

幻讀(Phantom read)

事務(wù)A 查詢id為age > 15的用戶，獲取到一個(gè)用戶，id為1，age為16的用戶

事務(wù)B 新增id為2，name為‘Bob’，age為22的用戶

事務(wù)A 再次查詢age > 15的用戶，獲取到兩個(gè)用戶

（1和3一個(gè)事務(wù) ，要理解成不可分割的最小執(zhí)行單元）
此時(shí)事務(wù)A兩次查詢不一樣，在一個(gè)事務(wù)重復(fù)讀數(shù)據(jù)的數(shù)量一樣，產(chǎn)生了幻覺(jué)，所謂的幻讀

臟讀：很好理解，事務(wù)中，讀取到臟數(shù)據(jù)。
不可重復(fù)讀：事務(wù)中，多次讀取同一個(gè)數(shù)據(jù)的內(nèi)容不一樣。(針對(duì)update)。
幻讀：事務(wù)中，多次讀取同一個(gè)條件數(shù)據(jù)的數(shù)量不一樣。（針對(duì)的是insert、delete）

如何解決上面三種問(wèn)題呢？往下看

事務(wù)四種隔離級(jí)別

SQL92，是數(shù)據(jù)庫(kù)的一個(gè)ANSI/ISO標(biāo)準(zhǔn)。它定義了一種語(yǔ)言（SQL）以及數(shù)據(jù)庫(kù)的行為（事務(wù)、隔離級(jí)別等）。

SQL92 ANSI/ISO標(biāo)準(zhǔn)：
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

四種隔離級(jí)別

Read Uncommitted（未提交讀） --未解決并發(fā)問(wèn)題

事務(wù)未提交對(duì)其他事務(wù)也是可見(jiàn)的，臟讀（dirty read）

Read Committed（提交讀） --解決臟讀問(wèn)題

一個(gè)事務(wù)開(kāi)始之后，只能看到自己提交的事務(wù)所做的修改，不可重復(fù)讀（nonrepeatableread）

Repeatable Read (可重復(fù)讀) --解決不可重復(fù)讀問(wèn)題

在同一個(gè)事務(wù)中多次讀取同樣的數(shù)據(jù)結(jié)果是一樣的，這種隔離級(jí)別未定義解決幻讀(Phantom read)的問(wèn)題

Serializable（串行化） --解決所有問(wèn)題

最高的隔離級(jí)別，通過(guò)強(qiáng)制事務(wù)的串行執(zhí)行

Innodb引擎對(duì)隔離級(jí)別的支持程度

事務(wù)隔離級(jí)別臟讀不可重復(fù)讀幻讀并發(fā)能力

Read Uncommitted（未提交讀）	可能	可能	可能	☆☆☆☆
Read Committed（提交讀）	不可能	可能	可能	☆☆☆
Repeatable Read（可重復(fù)讀）	不可能	可能不可能	對(duì)Innodb不可能	☆☆
Serializable（串行化）	不可能	不可能	不可能	☆

MySql鎖

? MySQL為什么要提供鎖機(jī)制？鎖能解決什么問(wèn)題？

? 如何保證數(shù)據(jù)并發(fā)訪問(wèn)的一致性、有效性是所在有數(shù)據(jù)庫(kù)必須解決的一個(gè)問(wèn)題，鎖沖突也是影響數(shù)據(jù)庫(kù)并發(fā)訪問(wèn)性能的一個(gè)重要因素。從這個(gè)角度來(lái)說(shuō)，鎖對(duì)數(shù)據(jù)庫(kù)而言顯得尤其重要，也更加復(fù)雜。

理解表鎖、行鎖

鎖是用于管理不同事務(wù)對(duì)共享資源的并發(fā)訪問(wèn)

表鎖與行鎖的區(qū)別：

鎖定粒度：表鎖 > 行鎖

加鎖效率：表鎖 > 行鎖

沖突概率：表鎖 > 行鎖

并發(fā)性能：表鎖 < 行鎖

InnoDB存儲(chǔ)引擎支持行鎖和表鎖（另類(lèi)的行鎖）

MySQL Innodb鎖類(lèi)型

MySQL Innodb鎖類(lèi)型一共有3種類(lèi)型

行鎖

共享鎖（行鎖）：Shared Locks
排它鎖（行鎖）：Exclusive Locks

表鎖

意向鎖共享鎖（表鎖）：Intention Shared Locks
意向鎖排它鎖（表鎖）：Intention Exclusive Locks

自增鎖

AUTO-INC Locks

下面3種是行鎖的算法

記錄鎖 Record Locks
間隙鎖 Gap Locks
臨鍵鎖 Next-key Locks

行鎖的算法https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html

共享鎖（Share Locks）vs 排它鎖（Exclusive Locks）

事務(wù)共享鎖 :又稱(chēng)為讀鎖，簡(jiǎn)稱(chēng)S鎖，顧名思義，共享鎖就是多個(gè)事務(wù)對(duì)于同一數(shù)據(jù)可以共享一把鎖，都能訪問(wèn)到數(shù)據(jù)，但是只能讀不能修改;

加鎖釋鎖方式：

select * from users WHERE id=1 LOCK IN SHARE MODE; commit/rollback

實(shí)例測(cè)試Share Locks

會(huì)話A autocommit關(guān)閉

##1、當(dāng)前會(huì)話A autocommit關(guān)閉 mysql> set session autocommit = OFF; Query OK, 0 rows affected (0.00 sec)mysql> show VARIABLES like 'autocommit'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | autocommit | OFF | +---------------+-------+ 1 row in set (0.01 sec)##2、查詢select mysql> select * from users WHERE id=1 LOCK IN SHARE MODE\G *************************** 1. row ***************************id: 1uname: 李二狗userLevel: 2age: 19phoneNum: 13666666666 createTime: 2021-01-23 15:39:46 lastUpdate: 2021-01-23 15:39:50 1 row in set (0.00 sec) ##3、當(dāng)前事務(wù)還沒(méi)提交或者回滾

會(huì)話B autocommit采用默認(rèn)的，未關(guān)閉

mysql> select * from users where id =1\G *************************** 1. row ***************************id: 1uname: 李二狗userLevel: 2age: 19phoneNum: 13666666666 createTime: 2021-01-23 15:39:46 lastUpdate: 2021-01-23 15:39:50 1 row in set (0.00 sec)mysql> update users set age=19 where id =1; ##這里修改會(huì)阻塞。。。 ##。。。等一會(huì)顯示 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

事務(wù)排他鎖:又稱(chēng)為寫(xiě)鎖，簡(jiǎn)稱(chēng)X鎖，排他鎖不能與其他鎖并存，如一個(gè)事務(wù)獲取了一個(gè)數(shù)據(jù)行的排他鎖，其他事務(wù)就不能再獲取該行的鎖（共享鎖、排他鎖），只有該獲取了排他鎖的事務(wù)是可以對(duì)數(shù)據(jù)行進(jìn)行讀取和修改，（其他事務(wù)要讀取數(shù)據(jù)可來(lái)自于快照//TODO 快照后面會(huì)將，待補(bǔ)充鏈接）

加鎖釋鎖方式：

delete / update / insert # 默認(rèn)加上X鎖SELECT * FROM table_name WHERE ... FOR UPDATE commit / rollback

實(shí)例測(cè)試
會(huì)話A

mysql> set session autocommit = OFF; Query OK, 0 rows affected (0.01 sec)mysql> show VARIABLES like 'autocommit'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | autocommit | OFF | +---------------+-------+ 1 row in set (0.01 sec)mysql> select * from users where id =1 for update\G *************************** 1. row ***************************id: 1uname: 李二狗userLevel: 2age: 19phoneNum: 13666666666 createTime: 2021-01-23 15:39:46 lastUpdate: 2021-01-23 15:39:50 1 row in set (29.50 sec) ##此時(shí)會(huì)話A拿到排它鎖

會(huì)話B

mysql> show VARIABLES like 'autocommit'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | autocommit | ON | +---------------+-------+ 1 row in set (0.02 sec)mysql> select * from users where id =1 for update\G ## 會(huì)阻塞。。。 ## 然后過(guò)一段時(shí)間超時(shí) ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction##在嘗試拿共享鎖（會(huì)話A要重新拿一次排它鎖，因?yàn)槲矣玫膌inux，這邊超時(shí)了，會(huì)話A的事務(wù)無(wú)效了） mysql> select * from users where id =1 lock in share mode\G ## 會(huì)阻塞。。。 ## 然后過(guò)一段時(shí)間超時(shí) ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Innodb到底鎖了什么？

InnoDB的行鎖是通過(guò)給索引上的索引項(xiàng)加鎖來(lái)實(shí)現(xiàn)的。

只有通過(guò)索引條件進(jìn)行數(shù)據(jù)檢索，InnoDB才使用行級(jí)鎖，否則，InnoDB將使用表鎖（鎖住索引的所有記錄）

意向共享鎖（IS）& 意向排他鎖

意向共享鎖(IS)

? 表示事務(wù)準(zhǔn)備給數(shù)據(jù)行加入共享鎖，即一個(gè)數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖，意向共享鎖之間是可以相互兼容的

意向排它鎖(IX)

? 表示事務(wù)準(zhǔn)備給數(shù)據(jù)行加入排他鎖，即一個(gè)數(shù)據(jù)行加排他鎖前必須先取得該表的IX鎖，意向排它鎖之間是可以相互兼容的

**意向鎖(IS、IX)**是InnoDB數(shù)據(jù)操作之前自動(dòng)加的，不需要用戶干預(yù)

意義：
當(dāng)事務(wù)想去進(jìn)行鎖表時(shí)，先嘗試拿意向鎖，意向拿不到，就不用去拿共享鎖、排他鎖

例如生活中的案例

? 一節(jié)火車(chē)車(chē)廂上的衛(wèi)生間WC會(huì)有一個(gè)指示燈，提示有人、無(wú)人，其他乘客只需要通過(guò)指示燈可以判斷衛(wèi)生間能否進(jìn)入，獲取使用權(quán)。這個(gè)指示燈就相當(dāng)于意向鎖，只是一個(gè)標(biāo)識(shí)。

? 乘客要獲取使用權(quán)衛(wèi)生間，不用進(jìn)入衛(wèi)生間查看是否有人，只需要看指示燈就行了。

? 事務(wù)要獲取一個(gè)數(shù)據(jù)行的鎖，要先獲取意向鎖。如果意向所獲取不到，就沒(méi)必要繼續(xù)獲取其共享鎖或排他鎖了，提高獲取鎖的性能。

自增鎖 AUTO-INC Locks

針對(duì)自增列自增長(zhǎng)的一個(gè)特殊的表級(jí)別鎖

默認(rèn)取值1，步長(zhǎng)為1，代表連續(xù)，事務(wù)未提交ID永久丟失

臨鍵鎖（Next-key）&間隙鎖（Gap）&記錄鎖（Record）

Gap locks：

鎖住數(shù)據(jù)不存在的區(qū)間（左開(kāi)右開(kāi)）
? 當(dāng)sql執(zhí)行按照索引進(jìn)行數(shù)據(jù)的檢索時(shí)，查詢條件的數(shù)據(jù)不存在，這時(shí)SQL語(yǔ)句加上的鎖即為Gap locks，鎖住索引不存在的區(qū)間（左開(kāi)右開(kāi)）

Record locks：

鎖住具體的索引項(xiàng)
? 當(dāng)sql執(zhí)行按照唯一性（Primary key、Unique key）索引進(jìn)行數(shù)據(jù)的檢索時(shí)，查詢條件等值匹配且查詢的數(shù)據(jù)是存在，這時(shí)SQL語(yǔ)句加上的鎖即為記錄鎖Record locks，鎖住具體的索引項(xiàng)

下面結(jié)合實(shí)例詳細(xì)介紹

數(shù)據(jù)準(zhǔn)備，比如數(shù)據(jù)庫(kù)中有一個(gè)表t,表結(jié)構(gòu)和數(shù)據(jù)如下：

mysql> desc t; +-------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | value | int(11) | NO | | NULL | | +-------+---------+------+-----+---------+----------------+ 2 rows in set (0.00 sec)mysql> select * from t; +----+-------+ | id | value | +----+-------+ | 1 | 1 | | 4 | 7 | | 7 | 7 | | 10 | 10 | +----+-------+ 4 rows in set (0.00 sec)

很簡(jiǎn)單的數(shù)據(jù)，只有4條

臨鍵鎖（Next-key）

Next-key locks：
? 鎖住記錄+區(qū)間（左開(kāi)右閉）
? 當(dāng)sql執(zhí)行按照索引進(jìn)行數(shù)據(jù)的檢索時(shí),查詢條件為范圍查找（between and、<、>等）并有數(shù)據(jù)命中則此時(shí)SQL語(yǔ)句加上的鎖為Next-key locks，鎖住索引的記錄+區(qū)間（左開(kāi)右閉）

為什么Innodb選擇臨鍵鎖Next-key作為行鎖的默認(rèn)算法？

防止幻讀，同時(shí)Innodb的默認(rèn)引擎是B+樹(shù)，其數(shù)據(jù)結(jié)構(gòu)特點(diǎn)就是連續(xù)遞增，且左開(kāi)右閉，所以使用Next-key策略

間隙鎖（Gap）

Gap只在RR事務(wù)隔離級(jí)別存在

記錄鎖（Record）

怎么利用鎖解決臟讀、不可重復(fù)讀、幻讀

解決臟讀用x鎖：

解決不可重復(fù)讀用s鎖：

解決幻讀用Next-key鎖：

死鎖介紹

多個(gè)并發(fā)事務(wù)（2個(gè)或者以上）；

每個(gè)事務(wù)都持有鎖（或者是已經(jīng)在等待鎖）;

每個(gè)事務(wù)都需要再繼續(xù)持有鎖；

事務(wù)之間產(chǎn)生加鎖的循環(huán)等待，形成死鎖。

小結(jié):我在等你、你在等我。

死鎖如何避免

類(lèi)似的業(yè)務(wù)邏輯以固定的順序訪問(wèn)表和行。

大事務(wù)拆小。大事務(wù)更傾向于死鎖，如果業(yè)務(wù)允許，將大事務(wù)拆小。

在同一個(gè)事務(wù)中，盡可能做到一次鎖定所需要的所有資源，減少死鎖概率。

降低隔離級(jí)別，如果業(yè)務(wù)允許，將隔離級(jí)別調(diào)低也是較好的選擇

為表添加合理的索引。可以看到如果不走索引將會(huì)為表的每一行記錄添加上鎖（或者說(shuō)是表鎖）

MVCC

先思考一個(gè)問(wèn)題

## 偽代碼 ## 查看mysql的設(shè)置的事務(wù)隔離級(jí)別 select @@tx_isolation; ex1：tx1: set session autocommit=off;update users set lastUpdate=now() where id =1;## 在未做commit/rollback操作之前## 在其他的事務(wù)我們能不能進(jìn)行對(duì)應(yīng)數(shù)據(jù)的查詢（特別是加上了X鎖的數(shù)據(jù)）tx2: select * from users where id > 1;select * from users where id = 1; ex2：tx1: beginselect * from users where id =1 ;tx2: beginupdate users set lastUpdate=now() where id =1;tx1:select * from users where id =1;

這兩個(gè)案例從結(jié)果上來(lái)看是一致的！底層實(shí)現(xiàn)是怎樣的呢？是一樣的嗎？他們的底層實(shí)現(xiàn)跟MVCC有什么關(guān)系么？

MVCC
? Multiversion concurrency control (多版本并發(fā)控制)

普通話解釋：
? 并發(fā)訪問(wèn)(讀或?qū)?數(shù)據(jù)庫(kù)時(shí)，對(duì)正在事務(wù)內(nèi)處理的數(shù)據(jù)做多版本的管理。以達(dá)到用來(lái)避免寫(xiě)操作的堵塞，從而引發(fā)讀操作的并發(fā)問(wèn)題。

MVCC實(shí)現(xiàn)
? MVCC是通過(guò)保存數(shù)據(jù)在某個(gè)時(shí)間點(diǎn)的快照來(lái)實(shí)現(xiàn)的. 不同存儲(chǔ)引擎的MVCC. 實(shí)現(xiàn)是不同的,典型的有樂(lè)觀并發(fā)控制和悲觀并發(fā)控制.

MVCC的具體實(shí)現(xiàn)分析
下面,我們通過(guò)InnoDB的MVCC實(shí)現(xiàn)來(lái)分析MVCC是怎樣進(jìn)行并發(fā)控制的

InnoDB的MVCC,是通過(guò)在每行記錄后面保存兩個(gè)隱藏的列來(lái)實(shí)現(xiàn)的,這兩個(gè)列，分別保存了這個(gè)行的創(chuàng)建時(shí)間（DB_TRX_ID），一個(gè)保存的是行的刪除時(shí)間（DB_ROLL_PT）。這里存儲(chǔ)的并不是實(shí)際的時(shí)間值,而是系統(tǒng)版本號(hào)(可以理解為事務(wù)的ID)，每開(kāi)始一個(gè)新的事務(wù)，系統(tǒng)版本號(hào)就會(huì)自動(dòng)遞增，事務(wù)開(kāi)始時(shí)刻的系統(tǒng)版本號(hào)會(huì)作為事務(wù)的ID.下面看一下在REPEATABLE READ隔離級(jí)別下,MVCC具體是如何操作的.

MySQL中MVCC邏輯流程

插入

假設(shè)系統(tǒng)的全局事務(wù)ID號(hào)從1開(kāi)始；

begin; -- 拿到系統(tǒng)的事務(wù)ID=1; insert into teacher(name,age) value ('sever',18); insert into teacher(name,age) value ('qingshan',19); commit;

如下圖，數(shù)據(jù)插入成功后，表后面兩列保存相應(yīng)的版本號(hào)

刪除

假設(shè)系統(tǒng)的全局事務(wù)ID號(hào)目前到了22

begin; -- 拿到系統(tǒng)的事務(wù)ID=22; delete teacher where id = 1; commit;

如下圖，id為2的數(shù)據(jù)行，刪除版本號(hào)設(shè)置為當(dāng)前事務(wù)ID(22)

修改

假設(shè)系統(tǒng)的全局事務(wù)ID號(hào)目前到了33

begin; -- 拿到系統(tǒng)的事務(wù)ID=33; update teacher set age = 19 where id = 1; commit;

修改操作是先做命中的數(shù)據(jù)行的copy，將原行數(shù)據(jù)的刪除版本號(hào)的值設(shè)置為當(dāng)前事務(wù)ID(33)

查詢

數(shù)據(jù)行查詢規(guī)則

查找數(shù)據(jù)行版本早于當(dāng)前事務(wù)版本的數(shù)據(jù)行（也就是，行的系統(tǒng)版本號(hào)小于或等于事務(wù)的系統(tǒng)版本號(hào)），這樣可以確保事務(wù)讀取的行，要么是在事務(wù)開(kāi)始前已經(jīng)存在的，要么是事務(wù)自身插入或者修改過(guò)的

查找刪除版本號(hào)要么為null，要么大于當(dāng)前事務(wù)版本號(hào)的記錄，確保取出來(lái)的行記錄在事務(wù)開(kāi)啟之前沒(méi)有被刪除
只有1,2同時(shí)滿足的記錄，才能返回作為查詢結(jié)果

假設(shè)系統(tǒng)的全局事務(wù)ID號(hào)目前到了44

begin; -- 拿到系統(tǒng)的事務(wù)ID=44; select * from teacher; commit;

MySQL中版本控制案例

數(shù)據(jù)準(zhǔn)備：

insert into teacher(name,age) value ('seven',18) ; insert into teacher(name,age) value ('qingshan',20) ; # tx1: begin; -- --------1 select * from users ; -- --------2 commit; # tx2： begin; -- --------3 update teacher set age =28 where id =1; -- --------4 commit;

案例1
按順序執(zhí)行 1，2，3，4，2

案例2
按順序執(zhí)行 3，4，1，2

案例一（1，2，3，4，2）

tx1 先執(zhí)行1,2

tx2 再執(zhí)行3,4

tx1 再執(zhí)行2

案例二（3、4、1、2）

tx2 先執(zhí)行3，4

tx1 再執(zhí)行1，2

案例二查詢結(jié)果不是我們想要的，mysql的Innodb也不是這樣做的。

寫(xiě)在最后

更多架構(gòu)知識(shí)，歡迎關(guān)注本套系列文章：Java架構(gòu)師成長(zhǎng)之路

總結(jié)

以上是生活随笔為你收集整理的性能优化专题 - MySql 性能优化 - 03 - 深入理解InnoDB的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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

上一篇： java查询多条_Mybatis查询多条
下一篇： class_create和class_d