MySQL基礎篇(06)：事務管理，鎖機制案例詳解

本文源碼：GitHub·點這裏 || GitEE·點這裏

1、鎖概念簡介

一、基礎描述

鎖機制核心功能是用來協調多個會話中多線程併發訪問相同資源時，資源的佔用問題。鎖機制是一個很是大的模塊，貫徹MySQL的幾大核心難點模塊：索引，鎖機制，事務。這裏是基於MySQL5.6演示的幾種典型場景，對面MySQL這幾塊問題時，有分析流程和思路是比較關鍵的。在MySQL中常見這些鎖概念：共享讀鎖、排它寫鎖 ; 表鎖、行鎖、間隙鎖。

二、存儲引擎和鎖

• MyISAM引擎：基於讀寫兩種模式，支持表級鎖 ;
• InnoDB引擎：支持行級別讀寫鎖，跨行的間隙鎖,InnoDB也支持表鎖 ;

三、鎖操做API

• LOCK TABLE name [READ,WRITE] ;加表鎖
• UNLOCK TABLES ; 釋放標所

2、MyISAM鎖機制

一、基礎描述

MySQL的表級鎖有兩種模式：共享讀鎖（Read-Lock）和排它寫鎖（Write-Lock）。針對MyISAM表的讀操做，不會阻塞其餘線程對同一表的讀請求，但阻塞對同一表的寫請求；針對MyISAM表的寫操做，會阻塞其餘線程對同一表的讀和寫操做；MyISAM引擎讀寫操做之間，以及寫與寫操做之間是串行化。當一次會話線程獲取表的寫鎖後，只有當前持有鎖的會話線程能夠對錶進行操做。其它線程的讀、寫操做都會等待，直到鎖被釋放爲止。

二、驗證案例

基於上面的表鎖機制特色，使用下面兩個案例驗證。

• 基礎表結構

CREATE TABLE `dc_user` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `user_name` varchar(20) DEFAULT NULL COMMENT '用戶名',
  `tell_phone` varchar(20) DEFAULT NULL COMMENT '手機號',
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='用戶表';
CREATE TABLE `dc_user_info` (
  `user_id` int(11) NOT NULL COMMENT '用戶ID',
  `city` varchar(20) DEFAULT NULL COMMENT '城市',
  `country` varchar(20) DEFAULT NULL COMMENT '國家',
  PRIMARY KEY (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='用戶信息表';

• 共享讀鎖

會話窗口一

-- 一、加讀鎖
LOCK TABLE dc_user READ ;
-- 二、當前會話查詢，OK
SELECT * FROM dc_user ;
-- 四、當前會話寫入，Error
INSERT INTO dc_user (user_name,tell_phone) VALUES ('lock01','13267788998');
-- 六、查詢其餘表,Error
SELECT * FROM dc_user_info ;
-- 七、釋放鎖
UNLOCK TABLES ;

會話窗口二

-- 三、其餘會話查詢，OK
SELECT * FROM dc_user ;
-- 五、其餘會話寫入，Error
INSERT INTO dc_user (user_name,tell_phone) VALUES ('lock01','13267788998');
-- 八、再次執行寫入讀取，OK
INSERT INTO dc_user (user_name,tell_phone) VALUES ('lock01','13267788998');
SELECT * FROM dc_user ;

這裏驗證表鎖的共享讀機制。

• 排它寫鎖

這裏驗證表鎖的排它寫機制。

• 查詢鎖爭用

經過下面語句查看配置，

show status like 'table%';

Table_locks_waited的值越大，鎖爭用狀況越嚴重，效率則越低下。

三、併發寫入問題

針對排它寫鎖的測試案例再說明：在必定條件下，MyISAM表也支持查詢和插入操做的併發執行。經過配置系統變量concurrent_insert的值[0,1,2]，能夠實現併發寫入。

• concurrent_insert=0，禁止併發寫入;
• concurrent_insert=1，默認配置AUTO，在MyISAM表中沒有空洞，即表的中間沒有被刪除的行，例如[1,2,3],刪除2以後[1,,3]，則容許在讀表的同時，另外一個線程從表尾寫入記錄。
• concurrent_insert=2，不管MyISAM表中有沒有空洞，都容許在表尾併發插入記錄。
  在下面的例子中，session_1得到了一個表的READ LOCAL鎖，該線程能夠對錶進行查詢操做，但不能對錶進行更新操做；其餘的線程（session_2），雖然不能對錶進行刪除和更新操做，但卻能夠對該表進行併發插入操做，這裏假設該表中間不存在空洞。

四、優先級問題

MyISAM存儲引擎的讀鎖和寫鎖是互斥的，讀寫操做是串行的。可是當一個讀操做和寫操做同時請求，寫數據會優先得到鎖，這一機制能夠經過配置修改，指定配置參數low-priority-updates，使MyISAM引擎默認給予讀請求以優先的權利。
經過執行命令SET

• LOW_PRIORITY_UPDATES=1，使該會話的寫操做優先級下降。
• 指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，下降該語句的優先級。

五、表鎖應用

數據一致性校驗問題，好比銷售量+剩餘庫存=貨品總量，在校驗時就要在一次會話中同時鎖住訂單表和庫存表，省得在讀取訂單表的時候，庫存表被修改，致使數據偏差出現。

3、InnoDB鎖機制

一、事務基礎概念

• 事務概念

事務是指做爲單個邏輯工做單元執行的一系列操做（SQL語句）。這些操做要麼所有成功，要麼所有不成功。

• 事務特性ACID

原子性(Atomicity)：事務中的多個操做要麼都成功要麼都失敗

一致性(consistency)：事務的執行的先後數據的完整性保持一致

隔離性(isolation)：事務執行的過程當中,不該該受到其餘事務的干擾

持久性(durability)：事務一旦結束,數據就持久到數據庫

• 事務問題

髒讀：一個事務讀到另外一個事務沒有提交的數據

不可重複讀：一個事務先後屢次讀取相同數據，數據內容不一致，update場景問題

虛讀(幻讀)：一個事務先後屢次讀取，數據總量不一致，insert場景問題

• 隔離級別

read uncommitted:事務能夠讀取另外一個未提交事務的數據。

read committed：事務要等另外一個事務提交後才能讀取數據,解決髒讀。

repeatable read：在開始讀取數據時,事務開啓,再也不容許修改操做,解決：髒讀、不可重複讀。

serializable：最高事務隔離級別，事務串行化順序執行，解決髒讀、不可重複讀、幻讀。可是效率低下，耗數據庫性能。

二、鎖機制描述

InnoDB與MyISAM的最大不一樣有兩點：一是支持事務TRANSACTION,二是採用了行級鎖。行級鎖與表級鎖原本就有許多不一樣之處，另外，事務的引入也帶來新問題：併發，死鎖等。

• 共享鎖：又稱讀鎖。容許一個事務去讀一行，阻止其餘事務得到相同數據集的排他鎖。若事務T對數據對象A加上共享鎖，則事務T能夠讀A但不能修改A，其餘事務只能再對A加共享鎖，而不能加寫鎖，直到T釋放A上的共享鎖。這保證了其餘事務能夠讀A，但在T釋放A上的S鎖以前不能對A作任何修改。

• 排他鎖：又稱寫鎖。容許獲取排他鎖的事務更新數據，阻止其餘事務取得相同的資源的共享讀鎖和排他鎖。若事務T對數據對象A加上寫鎖，事務T能夠讀A也能夠修改A，其餘事務不能再對A加任何鎖，直到T釋放A上的寫鎖。

三、驗證案例

• 基礎表結構

CREATE TABLE `dc_user_in01` (
  `id` int(11) DEFAULT NULL COMMENT 'id',
  `user_name` varchar(20) DEFAULT NULL COMMENT '用戶名',
  `tell_phone` varchar(20) DEFAULT NULL COMMENT '手機號'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶表';

CREATE TABLE `dc_user_in02` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `user_name` varchar(20) DEFAULT NULL COMMENT '用戶名',
  `tell_phone` varchar(20) DEFAULT NULL COMMENT '手機號',
  PRIMARY KEY (`id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8 COMMENT='用戶表';

注意結構：表dc_user_in01主鍵沒有索引。表dc_user_in02主鍵有索引，可是都使用INNODB存儲引擎，下面驗證案例會有不一樣。

• 無索引結構表

會話窗口一

-- 一、關閉自動提交
SET AUTOCOMMIT = 0 ;
-- 二、查詢id=1，OK
SELECT * FROM dc_user_in01 WHERE id=1 ;
-- 三、添加寫鎖失敗
SELECT * FROM dc_user_in01 
WHERE id=1 FOR UPDATE ;
-- 四、恢復事務提交
SET AUTOCOMMIT = 1 ;

會話窗口二

-- 一、關閉自動提交
SET AUTOCOMMIT = 0 ;
-- 二、查詢id=2，OK
SELECT * FROM dc_user_in01 WHERE id=2 ;
-- 三、寫入失敗(等待)
INSERT INTO dc_user_in01 (id,user_name,tell_phone) 
VALUES (3,'lock01','13267788998');
-- 四、寫鎖失敗(等待)
SELECT * FROM dc_user_in01 
WHERE id=2 FOR UPDATE ;
-- 五、恢復事務提交
SET AUTOCOMMIT=1 ;

• 索引結構表

會話窗口一

-- 一、關閉自動提交
SET AUTOCOMMIT = 0 ;
-- 二、查詢id=1，OK
SELECT * FROM dc_user_in02 WHERE id=1 ;
-- 三、添加寫鎖成功
SELECT * FROM dc_user_in02 WHERE id=1 FOR UPDATE ;
-- 執行到這裏，再執行窗口2
-- 四、恢復事務提交
SET AUTOCOMMIT = 1 ;

會話窗口二

-- 一、關閉自動提交
SET AUTOCOMMIT = 0 ;
-- 二、查詢id=2，OK
SELECT * FROM dc_user_in02 WHERE id=2 ;
-- 三、查詢id=1，OK，加讀鎖
SELECT * FROM dc_user_in02 WHERE id=1 ;
-- 四、寫入成功
INSERT INTO dc_user_in02 (user_name,tell_phone) VALUES ('lock01','13267788998');
-- 五、加寫鎖成功，id爲2的
SELECT * FROM dc_user_in02 
WHERE id=2 FOR UPDATE ;
-- 六、加寫鎖失敗(等待)，佔用id爲1的
SELECT * FROM dc_user_in02 WHERE id=1 FOR UPDATE ;
-- 七、恢復事務提交
SET AUTOCOMMIT=1 ;

• 索引失效問題

這裏要注意索引是否被使用問題，在不少查詢中，可能由於種種緣由致使索引不執行。

explain SELECT * FROM dc_user_in02 WHERE id=1 ;

• 查詢鎖爭用

show status like 'innodb_row_lock%';

Innodb_row_lock_waits和Innodb_row_lock_time_avg的值越大，鎖爭用狀況越嚴重，效率則越低下。

四、Next-Key鎖

• 官方文檔說明

爲了防止幻讀，InnoDB使用了一種名爲Next-Key鎖定的算法，它將記錄鎖和間隙鎖定結合在一塊兒即：InnoDB在執行行級鎖的時候，會用這種方式-掃描索引記錄，會在符合索引條件的記錄上加共享鎖或者獨佔鎖。

[Next-Key]=[Record-lock]+[Gap-lock]

若是說上面的幾種鎖機制給人的感受是昏天暗地，那個這個Next-Key算法就會叫人懷疑人生。

• 驗證案例

這裏主要驗證Gap-lock間隙鎖的存在機制。

CREATE TABLE `dc_gap` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `id_index` int(11) NOT NULL COMMENT 'index',
  PRIMARY KEY (`id`),
  KEY `id_index` (`id_index`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8 COMMENT='間隙表';
INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('1', '2');
INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('3', '4');
INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('6', '7');
INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('8', '7');
INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('9', '9');

會話窗口一

-- 一、開始事務
START TRANSACTION ;
-- 三、鎖定id_index=7的兩條記錄
SELECT * FROM dc_gap 
WHERE id_index=7 FOR UPDATE ;
-- 九、提交
COMMIT ;

會話窗口二

-- 二、開始事務
START TRANSACTION ;
-- 四、寫入等待,id_index=6
INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('4', '6');
-- 五、寫入等待,id_index=4
INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('4', '4');
-- 六、寫入成功,id_index=3
INSERT INTO `dc_gap` (`id`, `id_index`) 
VALUES ('4', '3');
-- 七、寫入等待,id_index=9
INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('7', '9');
-- 八、寫入成功,id_index=10
INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('7', '10');

7向上到4有間隙，7向下到9有間隙，因此間隙鎖定[4,9]，且包含首尾值。

五、Dead-Lock鎖

• 基礎描述

兩個或者多個事務在同一個資源上相互佔用，並請求鎖定對方佔用的資源，從而致使死循環現象，也就是死鎖。

• 驗證案例

會話窗口一

-- 一、開啓事務
START TRANSACTION ;
-- 三、佔用id=6的資源
SELECT * FROM dc_gap WHERE id=6 FOR UPDATE ;
-- 五、佔用id=9的資源等待
SELECT * FROM dc_gap WHERE id=9 FOR UPDATE ;

會話窗口二

-- 二、開啓事務
START TRANSACTION ;
-- 四、佔用id=9的資源
SELECT * FROM dc_gap WHERE id=9 FOR UPDATE ;
-- 六、佔用id=6的資源拋死鎖
SELECT * FROM dc_gap WHERE id=6 FOR UPDATE ;

補刀一句：數據庫實現各類死鎖檢測機制，或者死鎖超時等待結束，InnoDB存儲引擎在檢測到死鎖後，會當即返回錯誤，否則兩個事務會隔空對望，一眼萬年。

注意：死鎖在事務型業務中，是沒法絕對避免的，鎖定資源少，粒度細，儘可能避免該狀況出現。

4、源代碼地址

GitHub·地址
https://github.com/cicadasmile/mysql-data-base
GitEE·地址
https://gitee.com/cicadasmile/mysql-data-base