2. 程式人生 > >深入理解 MySQL ——鎖、事務與並發控制

深入理解 MySQL ——鎖、事務與並發控制

阿新 • • 發佈：2019-03-14
dcom 變化 show 希望 不包含 upd aci -a ner

本文首發於vivo互聯網技術微信公眾號 mp.weixin.qq.com/s/JFSDqI5ya…

作者：張碩

本文對 MySQL 數據庫中有關鎖、事務及並發控制的知識及其原理做了系統化的介紹和總結，希望幫助讀者能更加深刻地理解 MySQL 中的鎖和事務，從而在業務系統開發過程中可以更好地優化與數據庫的交互。

目錄

  1. MySQL 服務器邏輯架構
  2. MySQL 鎖
  3. 事務
  4. 隔離級別
  5. 並發控制 與 MVCC
  6. MySQL 死鎖問題

1、MySQL 服務器邏輯架構

技術分享圖片

（圖片來源MySQL官網）

每個連接都會在 MySQL 服務端產生一個線程（內部通過線程池管理線程），比如一個 select 語句進入，MySQL 首先會在查詢緩存中查找是否緩存了這個 select 的結果集，如果沒有則繼續執行解析、優化、執行的過程；否則會之間從緩存中獲取結果集。

2、MySQL 鎖

2.1、Shared and Exclusive Locks （共享鎖與排他鎖）

它們都是標準的行級鎖。

  • 共享鎖（S） 共享鎖也稱為讀鎖，讀鎖允許多個連接可以同一時刻並發的讀取同一資源,互不幹擾；
  • 排他鎖（X） 排他鎖也稱為寫鎖，一個寫鎖會阻塞其他的寫鎖或讀鎖，保證同一時刻只有一個連接可以寫入數據，同時防止其他用戶對這個數據的讀寫。

註意：所謂共享鎖、排他鎖其實均是鎖機制本身的策略，通過這兩種策略對鎖做了區分。

2.2、Intention Locks（意向鎖）

InnoDB 支持多粒度鎖(鎖粒度可分為行鎖和表鎖)，允許行鎖和表鎖共存。例如，一個語句，例如 LOCK TABLES…WRITE 接受指定表上的獨占鎖。為了實現多粒度級別的鎖定，InnoDB 使用了意圖鎖。

意向鎖：表級別的鎖。先提前聲明一個意向，並獲取表級別的意向鎖（共享意向鎖 IS 或排他意向鎖 IX），如果獲取成功，則稍後將要或正在(才被允許)，對該表的某些行加鎖(S或X)了。（除了 LOCK TABLES ... WRITE,會鎖住表中所有行，其他場景意向鎖實際不鎖住任何行)

舉例來說：

SELECT ... LOCK IN SHARE MODE，要獲取IS鎖；An intention shared lock (IS)

SELECT ... FOR UPDATE ，要獲取IX鎖；An intention exclusive lock (IX) i

意向鎖協議 在事務能夠獲取表中的行上的共享鎖之前，它必須首先獲取表上的IS鎖或更強的鎖。 在事務能夠獲取表中的行上的獨占鎖之前，它必須首先獲取表上的IX鎖。

前文說了，意向鎖實現的背景是多粒度鎖的並存場景。如下兼容性的匯總：

技術分享圖片

意向鎖僅表意向，是一種較弱的鎖，意向鎖之間兼容並行(IS、IX 之間關系兼容並行)。 X與IS\IX互斥；S與IX互斥。可以體會到，意向鎖是比X\S更弱的鎖，存在一種預判的意義！先獲取更弱的IX\IS鎖，如果獲取失敗就不必要再花費跟大開銷獲取更強的X\S鎖 ... ...

2.3、Record Locks (索引行鎖)

record lock 是一個在索引行記錄的鎖。

比如，SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE，如果c1 上的索引被使用到。防止任何其他事務變動 c1 = 10 的行。

record lock 總是會在索引行上加鎖。即使一個表並沒有設置任何索引，這種時候 innoDB 會創建一個隱式的聚集索引（primary Key）,然後在這個聚集索引上加鎖。

當查詢字段沒有索引時，比如 update table set columnA="A" where columnB=“B".如果 columnB 字段不存在索引（或者不是組合索引前綴），這條語句會鎖住所有記錄也就是鎖表。如果語句的執行能夠執行一個 columnB 字段的索引，那麽僅會鎖住滿足 where 的行(RecordLock)。

鎖出現查看示例：

(使用 show engine innodb status 命令查看)：

```範圍查詢
RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` 
trx id 10078 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 8000000a; asc     ;;
 1: len 6; hex 00000000274f; asc     ‘O;;
 2: len 7; hex b60000019d0110; asc        ;;

2.4、Gap locks（間隙鎖）

Gap Locks: 鎖定索引記錄之間的間隙([2])，或者鎖定一個索引記錄之前的間隙([1])，或者鎖定一個索引記錄之後的間隙([3])。

示例：如圖[1]、[2]、[3]部分。一般作用於我們的範圍篩選查詢> 、< 、between......

技術分享圖片

例如， SELECT userId FROM t1 WHERE userId BETWEEN 1 and 4 FOR UPDATE; 阻止其他事務將值3插入到列 userId 中。因為該範圍內所有現有值之間的間隙都是鎖定的。

  • 對於使用唯一索引來搜索唯一行的語句 select a from ，不產生間隙鎖定。(不包含組合唯一索引，也就是說 gapLock 不作用於單列唯一索引）

例如，如果id列有唯一的索引，下面的語句只對id值為100的行使用索引記錄鎖，其他會話是否在前一個間隙中插入行並不重要:

``` 
SELECT * FROM t1 WHERE id = 100;

```如果id**沒有索引或具有非惟一索引，則語句將鎖定前面的間隙**。
  • 間隙可以跨越單個索引值、多個索引值(如上圖2,3)，甚至是空的。
  • 間隙鎖是性能和並發性之間權衡的一種折衷，用於某些特定的事務隔離級別，如RC級別（RC級別：REPEATABLE READ，我司為了減少死鎖，關閉了gap鎖，使用RR級別）。
  • 在重疊的間隙中（或者說重疊的行記錄）中允許gap共存

比如同一個 gap 中，允許一個事務持有 gap X-Lock（gap 寫鎖\排他鎖)，同時另一個事務在這個 gap 中持有(gap 寫鎖\排他鎖)

CREATE TABLE `new_table` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` int(11) DEFAULT NULL,
  `b` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_new_table_a` (`a`),
  KEY `idx_new_table_b` (`b`)
) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8

INSERT INTO `new_table` VALUES (1,1,‘1‘),(2,3,‘2‘),(3,5,‘3‘),(4,8,‘4‘),(5,11,‘5‘),(6,2,‘6‘),(7,2,‘7‘),(8,2,‘8‘),(9,4,‘9‘),(10,4,‘10‘);



######## 事務一 ########
START TRANSACTION;
SELECT * FROM new_table WHERE a between 5 and 8 FOR UPDATE;
##暫不commit

######## 事務二 ########

SELECT * FROM new_table WHERE a = 4 FOR UPDATE;

##順利執行！ 因為gap鎖可以共存；


######## 事務三 ########

 SELECT * FROM new_table WHERE b = 3 FOR UPDATE;

##獲取鎖超時，失敗。因為事務一的gap鎖定了 b=3的數據。


2.5、next-key lock


next-key lock 是 record lock 與 gap lock 的組合。


比如 存在一個查詢匹配 b=3 的行(b上有個非唯一索引)，那麽所謂 NextLock 就是：在b=3 的行加了 RecordLock 並且使用 GapLock 鎖定了 b=3 之前（“之前”：索引排序）的所有行記錄。


MySQL 查詢時執行 行級鎖策略，會對掃描過程中匹配的行進行加鎖（X 或 S），也就是加Record Lock，同時會對這個記錄之前的所有行加 GapLock 鎖。 假設一個索引包含值10、11、13和20。該索引可能的NexKey Lock鎖定以下區間：



(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)



另外，值得一提的是 ： innodb 中默認隔離級別(RR)下，next key Lock 自動開啟。 （很好理解，因為 gap 作用於RR，如果是 RC，gapLock 不會生效，那麽 next key lock 自然也不會）


鎖出現查看示例： (使用 show engine innodb status 命令查看)：



RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` 
trx id 10080 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 8000000a; asc     ;;
 1: len 6; hex 00000000274f; asc     ‘O;;
 2: len 7; hex b60000019d0110; asc        ;;



 


2.6、Insert Intention Locks（插入意向鎖）


一個 insert intention lock 是一種發生在 insert 插入語句時的 gap lock 間隙鎖，鎖定插入行之前的所有行。


這個鎖以這樣一種方式表明插入的意圖，如果插入到同一索引間隙中的多個事務沒有插入到該間隙中的相同位置，則它們不需要等待對方。


假設存在值為4和7的索引記錄。嘗試分別插入值為5和6的獨立事務，在獲得所插入行上的獨占鎖之前，每個事務使用 insert intention lock 鎖定4和7之間的間隙，但不會阻塞彼此，因為這些行不沖突。


示例：



mysql> CREATE TABLE child (id int(11) NOT NULL, PRIMARY KEY(id)) ENGINE=InnoDB;
mysql> INSERT INTO child (id) values (90),(102);

##事務一
mysql> START TRANSACTION;
mysql> SELECT * FROM child WHERE id > 100 FOR UPDATE;
+-----+
| id  |
+-----+
| 102 |
+-----+
 

##事務二

mysql> START TRANSACTION;
mysql> INSERT INTO child (id) VALUES (101);
##失敗，已被鎖定

mysql> SHOW ENGINE INNODB STATUS

RECORD LOCKS space id 31 page no 3 n bits 72 index `PRIMARY` of table `test`.`child`
trx id 8731 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000066; asc    f;;
 1: len 6; hex 000000002215; asc     " ;;
 2: len 7; hex 9000000172011c; asc     r  ;;...





2.7、 AUTO-INC Locks


AUTO-INC 鎖是一種特殊的表級鎖，產生於這樣的場景：事務插入(inserting into )到具有 AUTO_INCREMENT 列的表中。


在最簡單的情況下，如果一個事務正在向表中插入值，那麽其他任何事務必須等待向該表中插入它們自己的值，以便由第一個事務插入的行接收連續的主鍵值。


2.8 Predicate Locks for Spatial Indexes 空間索引的謂詞鎖


略


 


3、事務


事務就是一組原子性的 sql，或者說一個獨立的工作單元。 事務就是說，要麽 MySQL 引擎會全部執行這一組sql語句，要麽全部都不執行（比如其中一條語句失敗的話）。


    

  • 自動提交（AutoCommit，MySQL 默認）
    • 




show variables like "autocommit";

set autocommit=0; //0表示AutoCommit關閉
set autocommit=1; //1表示AutoCommit開啟



MySQL 默認采用 AutoCommit 模式，也就是每個 sql 都是一個事務，並不需要顯示的執行事務。如果 autoCommit 關閉，那麽每個 sql 都默認開啟一個事務，只有顯式的執行“commit”後這個事務才會被提交。


    

  • 顯示事務 (START TRANSACTION...COMMIT)
    • 



比如，tim 要給 bill 轉賬100塊錢：


1.檢查 tim 的賬戶余額是否大於100塊；


2.tim 的賬戶減少100塊；


3.bill 的賬戶增加100塊；


這三個操作就是一個事務，必須打包執行，要麽全部成功， 要麽全部不執行，其中任何一個操作的失敗都會導致所有三個操作“不執行”——回滾。



CREATE DATABASE IF NOT EXISTS employees;
USE employees;

CREATE TABLE `employees`.`account` (
  `id` BIGINT (11) NOT NULL AUTO_INCREMENT,
  `p_name` VARCHAR (4),
  `p_money` DECIMAL (10, 2) NOT NULL DEFAULT 0,
  PRIMARY KEY (`id`)
) ;
INSERT INTO `employees`.`account` (`id`, `p_name`, `p_money`) VALUES (‘1‘, ‘tim‘, ‘200‘); 
INSERT INTO `employees`.`account` (`id`, `p_name`, `p_money`) VALUES (‘2‘, ‘bill‘, ‘200‘); 

START TRANSACTION;
SELECT p_money FROM account WHERE p_name="tim";-- step1
UPDATE account SET p_money=p_money-100 WHERE p_name="tim";-- step2
UPDATE account SET p_money=p_money+100 WHERE p_name="bill";-- step3
COMMIT;



一個良好的事務系統，必須滿足ACID特點：


 


3.1、事務的ACID：


    

  • A:atomiciy 原子性：一個事務必須保證其中的操作要麽全部執行，要麽全部回滾，不可能存在只執行了一部分這種情況出現。
    • 



    

  • C:consistency 一致性：數據必須保證從一種一致性的狀態轉換為另一種一致性狀態。 比如上一個事務中執行了第二步時系統崩潰了，數據也不會出現 bill 的賬戶少了100塊，但是 tim 的賬戶沒變的情況。要麽維持原裝（全部回滾），要麽 bill 少了100塊同時 tim 多了100塊，只有這兩種一致性狀態的。
    • 



    

  • I：isolation 隔離性：在一個事務未執行完畢時，通常會保證其他 Session 無法看到這個事務的執行結果。
    • 



    

  • D:durability 持久性：事務一旦 commit，則數據就會保存下來，即使提交完之後系統崩潰，數據也不會丟失。
    • 



 


4、隔離級別


 技術分享圖片



查看系統隔離級別：
select @@global.tx_isolation;
查看當前會話隔離級別
select @@tx_isolation;
設置當前會話隔離級別
SET session TRANSACTION ISOLATION LEVEL serializable;
設置全局系統隔離級別
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;



 


4.1、 READ UNCOMMITTED (未提交讀,可臟讀)


事務中的修改，即使沒有提交，對其他會話也是可見的。可以讀取未提交的數據——臟讀。臟讀會導致很多問題，一般不適用這個隔離級別。 實例：



-- ------------------------- read-uncommitted實例 ------------------------------
-- 設置全局系統隔離級別
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- Session A
START TRANSACTION;
SELECT * FROM USER;
UPDATE USER SET NAME="READ UNCOMMITTED";
-- commit;

-- Session B
SELECT * FROM USER;

//SessionB Console 可以看到Session A未提交的事物處理，在另一個Session 中也看到了，這就是所謂的臟讀
id    name
2    READ UNCOMMITTED
34    READ UNCOMMITTED





 


4.2、READ COMMITTED (提交讀或不可重復讀，幻讀)


一般數據庫都默認使用這個隔離級別（MySQL 不是）， 這個隔離級別保證了一個事務如果沒有完全成功（commit 執行完），事務中的操作對其他會話是不可見的。



-- ------------------------- read-cmmitted實例 ------------------------------
-- 設置全局系統隔離級別
SET GLOBAL TRANSACTION ISOLATION LEVEL READ  COMMITTED;
-- Session A
START TRANSACTION;
SELECT * FROM USER;
UPDATE USER SET NAME="READ COMMITTED";
-- COMMIT;

-- Session B
SELECT * FROM USER;

//Console OUTPUT:
id    name
2    READ UNCOMMITTED
34    READ UNCOMMITTED


---------------------------------------------------
-- 當 Session  A執行了commit，Session B得到如下結果：
id    name
2    READ COMMITTED
34    READ COMMITTED



也就驗證了 read committed 級別在事物未完成 commit 操作之前修改的數據對其他 Session 不可見，執行了 commit 之後才會對其他 Session 可見。 我們可以看到 Session B 兩次查詢得到了不同的數據。


read committed 隔離級別解決了臟讀的問題，但是會對其他 Session 產生兩次不一致的讀取結果（因為另一個 Session 執行了事務，一致性變化）。


 


4.3、 REPEATABLE READ (可重復讀)


一個事務中多次執行統一讀 SQL,返回結果一樣。 這個隔離級別解決了臟讀的問題，幻讀問題。這裏指的是 innodb 的 rr 級別，innodb 中使用 next-key 鎖對"當前讀"進行加鎖，鎖住行以及可能產生幻讀的插入位置，阻止新的數據插入產生幻行。 下文中詳細分析。具體請參考 MySQL 手冊：




https://dev.mysql.com/doc/refman/5.7/en/innodb-storage-engine.html




 


4.4、 SERIALIZABLE (可串行化)


最強的隔離級別，通過給事務中每次讀取的行加鎖，寫加寫鎖，保證不產生幻讀問題，但是會導致大量超時以及鎖爭用問題。


 


5、並發控制 與 MVCC


MVCC (multiple-version-concurrency-control）它是個行級鎖的變種， 在普通讀情況下避免了加鎖操作，因此開銷更低。雖然實現不同，但通常都是實現非阻塞讀，對於寫操作只鎖定必要的行。


    

  • 一致性讀 （就是讀取快照）select * from table ....
    • 



    

  • 當前讀(就是讀取實際的持久化的數據)特殊的讀操作，插入/更新/刪除操作，屬於當前讀，處理的都是當前的數據，需要加鎖。 select * from table where ? lock in share mode; select * from table where ? for update; insert; update ; delete;
    • 



註意：select ...... from where...... （沒有額外加鎖後綴）使用MVCC，保證了讀快照(MySQL 稱為 consistent read)，所謂一致性讀或者讀快照就是讀取當前事務開始之前的數據快照，在這個事務開始之後的更新不會被讀到。詳細情況下文 select 的詳述。


對於加鎖讀 SELECT with FOR UPDATE (排他鎖) or LOCK IN SHARE MODE (共享鎖)、 update、delete語句，要考慮是否是唯一索引的等值查詢。


INNODB 的 MVCC 通常是通過在每行數據後邊保存兩個隱藏的列來實現(其實是三列，第三列是用於事務回滾，此處略去)，一個保存了行的創建版本號，另一個保存了行的更新版本號（上一次被更新數據的版本號） 這個版本號是每個事務的版本號，遞增的。這樣保證了 innodb 對讀操作不需要加鎖也能保證正確讀取數據。


 


5.1、MVCC select無鎖操作 與 維護版本號


下邊在 MySQL 默認的 Repeatable Read 隔離級別下，具體看看 MVCC 操作：


    

  • Select（快照讀，所謂讀快照就是讀取當前事務之前的數據。）：a.InnoDB 只 select 查找版本號早於當前版本號的數據行，這樣保證了讀取的數據要麽是在這個事務開始之前就已經 commit 了的（早於當前版本號），要麽是在這個事務自身中執行創建操作的數據（等於當前版本號）。b.查找行的更新版本號要麽未定義，要麽大於當前的版本號(為了保證事務可以讀到老數據)，這樣保證了事務讀取到在當前事務開始之後未被更新的數據。註意： 這裏的 select 不能有 for update、lock in share 語句。 總之要只返回滿足以下條件的行數據，達到了快照讀的效果：
    • 



    

  • (行創建版本號< =當前版本號 && (行更新版本號==null or 行更新版本號>當前版本號 ) )
    • 



    

  • Insert  InnoDB為這個事務中新插入的行，保存當前事務版本號的行作為行的行創建版本號。
    • 



    

  • Delete InnoDB 為每一個刪除的行保存當前事務版本號，作為行的刪除標記。
    • 



    

  • Update  將存在兩條數據，保持當前版本號作為更新後的數據的新增版本號，同時保存當前版本號作為老數據行的更新版本號。
    • 



    

  • 當前版本號—寫—>新數據行創建版本號 && 當前版本號—寫—>老數據更新版本號();
    • 



 


5.2、臟讀 vs 幻讀 vs 不可重復讀


臟讀：一事務未提交的中間狀態的更新數據 被其他會話讀取到。


當一個事務正在訪問數據，並且對數據進行了修改， 而這種修改還沒有 提交到數據庫中(commit 未執行)， 這時，另外會話也訪問這個數據，因為這個數據是還沒有提交， 那麽另外一個會話讀到的這個數據是臟數據，依據臟數據所做的操作也可能是不正確的。


不可重復讀：簡單來說就是在一個事務中讀取的數據可能產生變化，ReadCommitted 也稱為不可重復讀。


在同一事務中，多次讀取同一數據返回的結果有所不同。 換句話說就是，後續讀取可以讀到另一會話事務已提交的更新數據。 相反，“可重復讀”在同一事務中多次讀取數據時，能夠保證所讀數據一樣， 也就是，後續讀取不能讀到另一會話事務已提交的更新數據。


幻讀：會話T1事務中執行一次查詢，然後會話T2新插入一行記錄，這行記錄恰好可以滿足T1所使用的查詢的條件。然後T1又使用相同 的查詢再次對表進行檢索，但是此時卻看到了事務T2剛才插入的新行。這個新行就稱為“幻像”，因為對T1來說這一行就像突然 出現的一樣。innoDB 的 RR 級別無法做到完全避免幻讀，下文詳細分析。


技術分享圖片


 


5.3、 如何保證 rr 級別絕對不產生幻讀？


在使用的 select ...where 語句中加入 for update (排他鎖) 或者 lock in share mode (共享鎖)語句來實現。其實就是鎖住了可能造成幻讀的數據，阻止數據的寫入操作。


其實是因為數據的寫入操作(insert 、update)需要先獲取寫鎖，由於可能產生幻讀的部分，已經獲取到了某種鎖，所以要在另外一個會話中獲取寫鎖的前提是當前會話中釋放所有因加鎖語句產生的鎖。


 


5.4、 從另一個角度看鎖：顯式鎖、隱式鎖


隱式鎖：我們上文說的鎖都屬於不需要額外語句加鎖的隱式鎖。


顯示鎖：


SELECT ... LOCK IN SHARE MODE(加共享鎖);
SELECT ... FOR UPDATE(加排他鎖);


詳情上文已經說過。


 


5.5、查看鎖情況


通過如下 sql 可以查看等待鎖的情況



select * from information_schema.innodb_trx where trx_state="lock wait";
或
show engine innodb status;





6、MySQL 死鎖問題


死鎖，就是產生了循環等待鏈條，我等待你的資源，你卻等待我的資源，我們都相互等待，誰也不釋放自己占有的資源，導致無線等待下去。 比如：



//Session A
START TRANSACTION;
UPDATE account SET p_money=p_money-100 WHERE p_name="tim";
UPDATE account SET p_money=p_money+100 WHERE p_name="bill";
COMMIT;
//Thread B
START TRANSACTION;
UPDATE account SET p_money=p_money+100 WHERE p_name="bill";
UPDATE account SET p_money=p_money-100 WHERE p_name="tim";
COMMIT;



當線程A執行到第一條語句UPDATE account SET p_money=p_money-100 WHERE p_name="tim";鎖定了p_name="tim" 的行數據；並且試圖獲取 p_name="bill" 的數據；


此時，恰好，線程B也執行到第一條語句：UPDATE account SET p_money=p_money+100 WHERE p_name="bill";鎖定了 p_name="bill" 的數據，同時試圖獲取 p_name="tim" 的數據；


此時，兩個線程就進入了死鎖，誰也無法獲取自己想要獲取的資源，進入無線等待中，直到超時！


innodb_lock_wait_timeout  等待鎖超時回滾事務：


直觀方法是在兩個事務相互等待時，當一個等待時間超過設置的某一閥值時，對其中一個事務進行回滾，另一個事務就能繼續執行。


這種方法簡單有效，在i nnodb 中，參數 innodb_lock_wait_timeout 用來設置超時時間。


wait-for graph 算法來主動進行死鎖檢測：innodb 還提供了 wait-for graph 算法來主動進行死鎖檢測，每當加鎖請求無法立即滿足需要並進入等待時，wait-for graph 算法都會被觸發。


 


6.1、如何盡可能避免死鎖


    

  • 以固定的順序訪問表和行。比如兩個更新數據的事務，事務A 更新數據的順序 為1，2；事務B更新數據的順序為2，1。這樣更可能會造成死鎖；
    • 



    

  • 大事務拆小。大事務更傾向於死鎖，如果業務允許，將大事務拆小；
    • 



    

  • 在同一個事務中，盡可能做到一次鎖定所需要的所有資源，減少死鎖概率；
    • 



    

  •  降低隔離級別。如果業務允許，將隔離級別調低也是較好的選擇，比如將隔離級別從RR調整為RC，可以避免掉很多因為gap鎖造成的死鎖。（我司 MySQL 規範做法）；
    • 



    

  • 為表添加合理的索引。可以看到如果不走索引將會為表的每一行記錄添加上鎖，死鎖的概率大大增大。
    • 





延伸閱讀： 


    

  •  MySQL官網參考文檔：https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html
    • 



    

  • 更多內容敬請關註 vivo互聯網技術 微信公眾號。
    • 



技術分享圖片


版權聲明：轉載文章請先與微信號 labs2020 聯系。
深入理解 MySQL ——鎖、事務與並發控制
   
 
 
 
 

            
  

           

              
              

            

            
相關推薦

			   
            
            
            
 

    


    
    
深入理解 MySQL ——鎖、事務與並發控制

     
 dcom   變化   show   希望   不包含   upd   aci   -a   ner    



本文首發於vivo互聯網技術微信公眾號 mp.weixin.qq.com/s/JFSDqI5ya…
作者：張碩
本文對 MySQL 數據庫中有關鎖、事務及並發控制的知識 



  
 

    


    
    
深入理解Mysql——鎖、事務與併發控制

     
 
                下面大部分博文轉自https://blog.csdn.net/lemon89/article/details/51477497



SQL 語句主要可以劃分為以下 3 個類別。

DDL（Data Definition Languages）語句：資料定義語言，這些語句定義了 



  
 

    


    
    
進程與線程、並行與並發的理解

     
 實體   定義   命令   計數器   執行   大於   運行   系統   其它   進程與線程
1.定義
 
進程是具有一定獨立功能的程序關於某個數據集合上的一次運行活動,進程是系統進行資源分配和調度的一個獨立單位.
線程是進程的一個實體,是CPU調度和分派的基本單位,它是比進程更小的能獨立運行的基本 



  
 

    


    
    
34、mysql鎖、事務、隔離

     
 
 連線池    與使用者請求建立連線
 核心功能層         查詢解析，分析，優化，內建函式,跨儲存引擎的功能
 儲存引擎層        & 



  
 

    


    
    
postgresql事務處理與並發控制

     
 但是   變化   ins   珍惜   事務日誌   映射   cti   ransac   l命令   postgresql事務處理與並發控制：事務是postgresql中的基本工作單元，是用戶定義的一個數據庫操作序列。這些操作要麽全做，要麽全不做，是一個不可分割的工作單位。在postgresql中，事務 



  
 

    


    
    
Anatomy of a Database System學習筆記 - 事務：並發控制與恢復

     
 unp   供應商   format   要求   獲取   處理   因此   coupling   相對   這一章看起來是講存儲引擎的。作者抱怨數據庫被黑為“monolithic”、不可拆分為可復用的組件；但是實際上除了事務存儲引擎管理模塊，其他模塊入解析器、重寫引擎、優化器、執 



  
 

    


    
    
[數據庫事務與鎖]詳解七: 深入理解樂觀鎖與悲觀鎖

     
 ood   insert   影響   hiberna   memcach   begin   策略   goods   其它   
註明: 本文轉載自http://www.hollischuang.com/archives/934在數據庫的鎖機制中介紹過，數據庫管理系統（DBMS）中的並發控制的任務是確保在 



  
 

    


    
    
理解mysql的鎖、事務隔離級別及事務傳播行為

     
  
 
 
  資料庫事務(Database Transaction) ，是指作為單個邏輯工作單元執行的一系列操作，要麼完全地執行，要麼完全地不執行。
   ACID，是指在可靠資料庫管理系統（DBMS）中，事務(Transaction)所應該具有的四個特性：原子性（Atomicity）、一致性（Consis 



  
 

    


    
    
分布式緩存技術redis學習系列（三）——redis高級應用（主從、事務與鎖、持久化）

     
 master   ica   not   ood   www   working   can   出了   owin   上文《詳細講解redis數據結構（內存模型）以及常用命令》介紹了redis的數據類型以及常用命令，本文我們來學習下redis的一些高級特性。
 
回到頂部
安全性設置
設置客戶端操作秘密
 



  
 

    


    
    
Mysql事務，並發問題，鎖機制

     
 記錄   其中   什麽是   原子性   結果   內部   個數   執行   處理   1、什麽是事務
事務是一條或多條數據庫操作語句的組合，具備ACID，4個特點。
原子性：要不全部成功，要不全部撤銷
隔離性：事務之間相互獨立，互不幹擾
一致性：數據庫正確地改變狀態後，數據庫的一致性約束沒有被破壞
持 



  
 

    


    
    
深入理解樂觀鎖與悲觀鎖

     
 遇到   實現   個數   默認   ODB   date   開始   安全   行數   前言在數據庫的鎖機制中介紹過，數據庫管理系統（DBMS）中的並發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。
樂觀並發控制(樂觀鎖)和悲觀並發控制（悲觀鎖）是並 



  
 

    


    
    
MySQL的並發控制與加鎖分析

     
 開啟   bubuko   最新版本   行數據   我們   控制   刪除   阻塞   一致性   本文主要是針對MySQL/InnoDB的並發控制和加鎖技術做一個比較深入的剖析，並且對其中涉及到的重要的概念，如多版本並發控制（MVCC），臟讀（dirty read），幻讀（phantom read）， 



  
 

    


    
    
最簡單理解Mysql共享、排他鎖和樂觀、悲觀鎖

     
  
 
 
 共享鎖 select * from xx where id = 10 lock in share mode 
 排他鎖 select * from xx where id = 10 for update 
 樂觀鎖 select num,version from xx where id = 10 



  
 

    


    
    
資料庫併發訪問、事務與鎖、髒讀、不可重複讀、幻讀

     
  
 
 資料庫併發訪問、事務與鎖的關係 
 一、事務 
 I : 事務的定義： 
 首先，讓我們瞭解下什麼是事務？事務是作為單個邏輯單元工作執行的一系列操作。可以是一條 sql語句，也可以是多條 sql 語句 ( 這是它的描述性定義&nb 



  
 

    


    
    
【資料庫視訊】事務、鎖、系統與原資料函式、BEGIN…END

     
  
 
 一、事務 
 管理語句： 
 
   BEGIN  TRANSACTION（開啟）  
   COMMIT  TRANSACTION（提交）  
   ROLLBACK  TRANSACTION（回滾）  
   SAVE  TRANSACTION（儲存）   



  
 

    


    
    
深入理解Javascript中的堆與棧、淺拷貝與深拷貝

     
  
  
  
 Javascript中的淺拷貝與深拷貝 先從JavaScript的資料型別存放的位置堆疊開始說吧 什麼是堆疊？ 我們知道計算機領域中堆疊是兩種資料結構，它們只能再一端(稱為棧頂(top))對資料項進行插入和刪除。 堆：佇列優先，先進先出，由作業系統自動分配釋放，存放函式的引數值，區域性變數的 



  
 

    


    
    
深入理解MySQL索引底層資料結構與演算法

     
 
								
								            
						
                一 理解索引的特性

索引是幫助MySQL高效獲取資料的排好序的資料結構
	索引儲存在檔案裡
二 索引的各種儲存結構及其優缺點

在開始講這一小節之前，我們先來看一下在資料庫沒有加索引的情況下，SQL中 



  
 

    


    
    
深入理解MySQL的MDL元資料鎖

     
 
				
前言
好久沒更新，主要是因為Inside君最近沉迷於一部動畫片——《新葫蘆娃兄弟》。終於抽得閒，完成了本篇關於MySQLMDL鎖的深入分析與介紹。雖然之前有很多小夥伴分析過，但總感覺少了點什麼，故花了點時間翻看了下原始碼。Inside君或許不是最牛掰的核心開發人員，但自認為應該是業界最會講故事的碼 



  
 

    


    
    
MySQL中的事務與鎖

     
  
 
  
   事務 
   資料庫事務（簡稱：事務）是資料庫管理系統執行過程中的一個邏輯單位，由一個有限的資料庫操作序列構成。一個數據庫事務通常包含了一個序列的對資料庫的讀/寫操作。它的存在包含有以下兩個目的： 
   
   
    
     
      
       1
2
  
      



  
 

    


    
    
深入理解Http請求、DNS劫持與解析

     
 前段時間在處理iOS端的HTTPDNS相關SDK，在接入和測試環節發現大家對HTTP的整體請求流程包括HTTP劫持原理以及HTTPDNS的工作原理並不是太清楚，所以寫下這邊文章幫助大家深入web請求過程：如何發起請求，HTTP協議解析，DNS域名解析。HTTP發起一個請求過程當我們在手機端請求一個@"www.