本文原始碼：[GitHub·點這裡](https://github.com/cicadasmile/mysql-data-base) || [GitEE·點這裡](https://github.com/cicadasmile/mysql-data-base) # 一、鎖概念簡介 ## 1、基礎描述 鎖機制核心功能是用來協調多個會話中多執行緒併發訪問相同資源時，資源的佔用問題。鎖機制是一個非常大的模組，貫徹MySQL的幾大核心難點模組：索引，鎖機制，事務。這裡是基於MySQL5.6演示的幾種典型場景，對面MySQL這幾塊問題時，有分析流程和思路是比較關鍵的。在MySQL中常見這些鎖概念：共享讀鎖、排它寫鎖 ; 表鎖、行鎖、間隙鎖。 ## 2、儲存引擎和鎖 - MyISAM引擎：基於讀寫兩種模式，支援表級鎖 ; - InnoDB引擎：支援行級別讀寫鎖，跨行的間隙鎖,InnoDB也支援表鎖 ; ## 3、鎖操作API - LOCK TABLE name [READ,WRITE] ;加表鎖 - UNLOCK TABLES ; 釋放標所 # 二、MyISAM鎖機制 ## 1、基礎描述 MySQL的表級鎖有兩種模式：共享讀鎖（Read-Lock）和排它寫鎖（Write-Lock）。針對MyISAM表的讀操作，不會阻塞其他執行緒對同一表的讀請求，但阻塞對同一表的寫請求；針對MyISAM表的寫操作，會阻塞其他執行緒對同一表的讀和寫操作；MyISAM引擎讀寫操作之間，以及寫與寫操作之間是序列化。當一次會話執行緒獲取表的寫鎖後，只有當前持有鎖的會話執行緒可以對錶進行操作。其它執行緒的讀、寫操作都會等待，直到鎖被釋放為止。 ## 2、驗證案例 基於上面的表鎖機制特點，使用下面兩個案例驗證。 - **基礎表結構** ``` 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='使用者資訊表'; ``` - **共享讀鎖**  **會話視窗一** ```sql -- 1、加讀鎖 LOCK TABLE dc_user READ ; -- 2、當前會話查詢，OK SELECT * FROM dc_user ; -- 4、當前會話寫入，Error INSERT INTO dc_user (user_name,tell_phone) VALUES ('lock01','13267788998'); -- 6、查詢其他表,Error SELECT * FROM dc_user_info ; -- 7、釋放鎖 UNLOCK TABLES ; ``` **會話視窗二** ```sql -- 3、其他會話查詢，OK SELECT * FROM dc_user ; -- 5、其他會話寫入，Error INSERT INTO dc_user (user_name,tell_phone) VALUES ('lock01','13267788998'); -- 8、再次執行寫入讀取，OK INSERT INTO dc_user (user_name,tell_phone) VALUES ('lock01','13267788998'); SELECT * FROM dc_user ; ``` 這裡驗證表鎖的共享讀機制。 - **排它寫鎖**  這裡驗證表鎖的排它寫機制。 - **查詢鎖爭用** 通過下面語句檢視配置， ```sql show status like 'table%'; ``` Table_locks_waited的值越大，鎖爭用情況越嚴重，效率則越低下。 ## 3、併發寫入問題 針對排它寫鎖的測試案例再說明：在一定條件下，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），雖然不能對錶進行刪除和更新操作，但卻可以對該表進行併發插入操作，這裡假設該表中間不存在空洞。 ## 4、優先順序問題 MyISAM儲存引擎的讀鎖和寫鎖是互斥的，讀寫操作是序列的。但是當一個讀操作和寫操作同時請求，寫資料會優先獲得鎖，這一機制可以通過配置修改，指定配置引數low-priority-updates，使MyISAM引擎預設給予讀請求以優先的權利。 通過執行命令SET - LOW_PRIORITY_UPDATES=1，使該會話的寫操作優先順序降低。 - 指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優先順序。 ## 5、表鎖應用 資料一致性校驗問題，比如銷售量+剩餘庫存=貨品總量，在校驗時就要在一次會話中同時鎖住訂單表和庫存表，免得在讀取訂單表的時候，庫存表被修改，導致資料誤差出現。 # 三、InnoDB鎖機制 ## 1、事務基礎概念 - **事務概念** 事務是指作為單個邏輯工作單元執行的一系列操作（SQL語句）。這些操作要麼全部成功，要麼全部不成功。 - **事務特性ACID** **原子性(Atomicity)**：事務中的多個操作要麼都成功要麼都失敗 **一致性(consistency)**：事務的執行的前後資料的完整性保持一致 **隔離性(isolation)**：事務執行的過程中,不應該受到其他事務的干擾 **永續性(durability)**：事務一旦結束,資料就持久到資料庫 - **事務問題** **髒讀**：一個事務讀到另一個事務沒有提交的資料 **不可重複讀**：一個事務前後多次讀取相同資料，資料內容不一致，update場景問題 **虛讀(幻讀)**：一個事務前後多次讀取，資料總量不一致，insert場景問題 - **隔離級別** **read uncommitted**:事務可以讀取另一個未提交事務的資料。 **read committed**：事務要等另一個事務提交後才能讀取資料,解決髒讀。 **repeatable read**：在開始讀取資料時,事務開啟,不再允許修改操作,解決：髒讀、不可重複讀。 **serializable**：最高事務隔離級別，事務序列化順序執行，解決髒讀、不可重複讀、幻讀。但是效率低下，耗資料庫效能。 ## 2、鎖機制描述 InnoDB與MyISAM的最大不同有兩點：一是支援事務TRANSACTION,二是採用了行級鎖。行級鎖與表級鎖本來就有許多不同之處，另外，事務的引入也帶來新問題：併發，死鎖等。 - 共享鎖：又稱讀鎖。允許一個事務去讀一行，阻止其他事務獲得相同資料集的排他鎖。若事務T對資料物件A加上共享鎖，則事務T可以讀A但不能修改A，其他事務只能再對A加共享鎖，而不能加寫鎖，直到T釋放A上的共享鎖。這保證了其他事務可以讀A，但在T釋放A上的S鎖之前不能對A做任何修改。 - 排他鎖：又稱寫鎖。允許獲取排他鎖的事務更新資料，阻止其他事務取得相同的資源的共享讀鎖和排他鎖。若事務T對資料物件A加上寫鎖，事務T可以讀A也可以修改A，其他事務不能再對A加任何鎖，直到T釋放A上的寫鎖。 ## 3、驗證案例 - **基礎表結構** ```sql 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儲存引擎，下面驗證案例會有不同。 - **無索引結構表**  **會話視窗一** ```sql -- 1、關閉自動提交 SET AUTOCOMMIT = 0 ; -- 2、查詢id=1，OK SELECT * FROM dc_user_in01 WHERE id=1 ; -- 3、新增寫鎖失敗 SELECT * FROM dc_user_in01 WHERE id=1 FOR UPDATE ; -- 4、恢復事務提交 SET AUTOCOMMIT = 1 ; ``` **會話視窗二** ```sql -- 1、關閉自動提交 SET AUTOCOMMIT = 0 ; -- 2、查詢id=2，OK SELECT * FROM dc_user_in01 WHERE id=2 ; -- 3、寫入失敗(等待) INSERT INTO dc_user_in01 (id,user_name,tell_phone) VALUES (3,'lock01','13267788998'); -- 4、寫鎖失敗(等待) SELECT * FROM dc_user_in01 WHERE id=2 FOR UPDATE ; -- 5、恢復事務提交 SET AUTOCOMMIT=1 ; ``` - **索引結構表**  **會話視窗一** ```sql -- 1、關閉自動提交 SET AUTOCOMMIT = 0 ; -- 2、查詢id=1，OK SELECT * FROM dc_user_in02 WHERE id=1 ; -- 3、新增寫鎖成功 SELECT * FROM dc_user_in02 WHERE id=1 FOR UPDATE ; -- 執行到這裡，再執行視窗2 -- 4、恢復事務提交 SET AUTOCOMMIT = 1 ; ``` **會話視窗二** ```sql -- 1、關閉自動提交 SET AUTOCOMMIT = 0 ; -- 2、查詢id=2，OK SELECT * FROM dc_user_in02 WHERE id=2 ; -- 3、查詢id=1，OK，加讀鎖 SELECT * FROM dc_user_in02 WHERE id=1 ; -- 4、寫入成功 INSERT INTO dc_user_in02 (user_name,tell_phone) VALUES ('lock01','13267788998'); -- 5、加寫鎖成功，id為2的 SELECT * FROM dc_user_in02 WHERE id=2 FOR UPDATE ; -- 6、加寫鎖失敗(等待)，佔用id為1的 SELECT * FROM dc_user_in02 WHERE id=1 FOR UPDATE ; -- 7、恢復事務提交 SET AUTOCOMMIT=1 ; ``` - **索引失效問題** 這裡要注意索引是否被使用問題，在很多查詢中，可能因為種種原因導致索引不執行。 ```sql explain SELECT * FROM dc_user_in02 WHERE id=1 ; ``` - **查詢鎖爭用** ```sql show status like 'innodb_row_lock%'; ``` Innodb_row_lock_waits和Innodb_row_lock_time_avg的值越大，鎖爭用情況越嚴重，效率則越低下。 ## 4、Next-Key鎖 - **官方文件說明** 為了防止幻讀，InnoDB使用了一種名為Next-Key鎖定的演算法，它將記錄鎖和間隙鎖定結合在一起即：InnoDB在執行行級鎖的時候，會用這種方式-掃描索引記錄，會在符合索引條件的記錄上加共享鎖或者獨佔鎖。 ```sql [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'); ```  **會話視窗一** ```sql -- 1、開始事務 START TRANSACTION ; -- 3、鎖定id_index=7的兩條記錄 SELECT * FROM dc_gap WHERE id_index=7 FOR UPDATE ; -- 9、提交 COMMIT ; ``` **會話視窗二** ```sql -- 2、開始事務 START TRANSACTION ; -- 4、寫入等待,id_index=6 INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('4', '6'); -- 5、寫入等待,id_index=4 INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('4', '4'); -- 6、寫入成功,id_index=3 INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('4', '3'); -- 7、寫入等待,id_index=9 INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('7', '9'); -- 8、寫入成功,id_index=10 INSERT INTO `dc_gap` (`id`, `id_index`) VALUES ('7', '10'); ``` 7向上到4有間隙，7向下到9有間隙，所以間隙鎖定[4,9]，且包含首尾值。 ## 5、Dead-Lock鎖 - **基礎描述** 兩個或者多個事務在同一個資源上相互佔用，並請求鎖定對方佔用的資源，從而導致死迴圈現象，也就是死鎖。 - **驗證案例**  **會話視窗一** ```sql -- 1、開啟事務 START TRANSACTION ; -- 3、佔用id=6的資源 SELECT * FROM dc_gap WHERE id=6 FOR UPDATE ; -- 5、佔用id=9的資源等待 SELECT * FROM dc_gap WHERE id=9 FOR UPDATE ; ``` **會話視窗二** ```sql -- 2、開啟事務 START TRANSACTION ; -- 4、佔用id=9的資源 SELECT * FROM dc_gap WHERE id=9 FOR UPDATE ; -- 6、佔用id=6的資源拋死鎖 SELECT * FROM dc_gap WHERE id=6 FOR UPDATE ; ``` `補刀一句`：資料庫實現各種死鎖檢測機制，或者死鎖超時等待結束，InnoDB儲存引擎在檢測到死鎖後，會立即返回錯誤，不然兩個事務會隔空對望，一眼萬年。 `注意`：死鎖在事務型業務中，是無法絕對避免的，鎖定資源少，粒度細，儘量避免該情況出現。 # 四、原始碼地址 ``` GitHub·地址 https://github.com/cicadasmile/mysql-data-base GitEE·地址 https://gitee.com/cicadasmile/mysql-data-base ``` ![](https://img2018.cnblogs.com/blog/1691717/201908/1691717-20190823075428183-1996768