1、鎖定義

　　鎖是計算機協調多個進程或線程併發訪問某一資源的機制。
　　在數據庫中，除了傳統的計算資源（如CPU、RAM、I/O等）的爭用以外，數據也是一種供需要用戶共享的資源。如何保證數據併發訪問的一致性、有效性是所有數據庫必須解決的一個問題，鎖衝突也是影響數據庫併發訪問性能的一個重要因素。

2、鎖分類

從性能上分爲樂觀鎖(用版本對比來實現) 和悲觀鎖；
從對數據庫操作的類型分，分爲讀鎖和寫鎖(都屬於悲觀鎖)；

　　讀鎖（共享鎖）：針對同一份數據，多個讀操作可以同時進行而不會互相影響；
　　寫鎖（排它鎖）：當前寫操作沒有完成前，它會阻斷其他寫鎖和讀鎖；

從對數據操作的粒度分，分爲表鎖和行鎖；

2.1 表鎖

每次操作鎖住整張表。開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的概率最高，併發度最低；

#建表SQL（MyISAM存儲引擎）
CREATE TABLE `mylock` (
  `id` INT (11) NOT NULL AUTO_INCREMENT,
  `NAME` VARCHAR (20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE = MyISAM DEFAULT CHARSET = utf8;

#插入數據
INSERT INTO `mylock` (`id`, `NAME`) VALUES ('1', 'a');
INSERT INTO `mylock` (`id`, `NAME`) VALUES ('2', 'b');
INSERT INTO `mylock` (`id`, `NAME`) VALUES ('3', 'c');
INSERT INTO `mylock` (`id`, `NAME`) VALUES ('4', 'd');

手動增加表鎖： lock table 表名稱 read(write), 表名稱2 read(write)；
查看錶上加過的鎖：show open tables;
刪除表鎖：unlock tables;

表鎖的使用：一般在數據的遷移中使用，使數據不會被修改；

（1）增加讀鎖

我們打開一個命令行窗口，執行以下 SQL：

當前session和其他session都可以讀該表；
當前session中插入或者更新鎖定的表都會報錯，其他session插入或更新則會等待；

執行： show open tables; 結果如下，可以看到 mylock 表加鎖了；

　　我們重新打開一個MySQL 的連接窗口，執行 select * from mylock where id = 1; 發現是可以查詢到數據的；接着我們執行 update mylock set name 'zhangsan' where id = 1; 會發現這個更新的 SQL 會一直卡在這裏不會執行結束，這是因爲表加了讀鎖；

　　在剛纔加表鎖的窗口中，我們執行 unlock tables; （刪除表鎖），可以看到發現更新的那個SQL語句給執行完成了；

（2）增加寫鎖

當前session對該表的增刪改查都沒有問題，其他session對該表的所有操作被阻塞；

結論：

MyISAM在執行查詢語句(SELECT)前，會自動給涉及的所有表加讀鎖，在執行增刪改操作前,會自動給涉及的表加寫鎖。
1、對MyISAM表的讀操作(加讀鎖) ,不會阻寒其他進程對同一表的讀請求,但會阻賽對同一表的寫請求。只有當讀鎖釋放後,纔會執行其它進程的寫操作。
2、對MylSAM表的寫操作(加寫鎖) ,會阻塞其他進程對同一表的讀和寫操作,只有當寫鎖釋放後,纔會執行其它進程的讀寫操作
總結：
簡而言之，就是讀鎖會阻塞寫，但是不會阻塞讀。而寫鎖則會把讀和寫都阻塞。

2.2 行鎖

每次操作鎖住一行數據。開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低，併發度最高。
InnoDB 與 MYISAM 的最大不同有兩點：

支持事務（TRANSACTION）
支持行級鎖

2.2.1 行鎖支持事務

事務（Transaction）及其ACID屬性

　　事務是由一組SQL語句組成的邏輯處理單元,事務具有以下4個屬性,通常簡稱爲事務的ACID屬性。
　　原子性(Atomicity) ：事務是一個原子操作單元,其對數據的修改,要麼全都執行,要麼全都不執行。
　　一致性(Consistent) ：在事務開始和完成時,數據都必須保持一致狀態。這意味着所有相關的數據規則都必須應用於務的修改,以保持數據的完整性;事務結束時,所有的內部數據結構(如B樹索引或雙向鏈表)也都必須是正確的。
　　隔離性(Isolation) ：數據庫系統提供一定的隔離機制,保證事務在不受外部併發操作影響的“獨立”環境執行。這意味着事務處理過程中的中間狀態對外部是不可見的,反之亦然。
　　持久性(Durable) ：事務完成之後,它對於數據的修改是永久性的,即使出現系統故障也能夠保持。

併發事務處理帶來的問題

　　更新丟失（Lost Update）
　　當兩個或多個事務選擇同一行，然後基於最初選定的值更新該行時，由於每個事務都不知道其他事務的存在，就會發生丟失更新問題–最後的更新覆蓋了由其他事務所做的更新。
　　髒讀（Dirty Reads）
　　一個事務正在對一條記錄做修改，在這個事務完成並提交前，這條記錄的數據就處於不一致的狀態；這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些“髒”數據，並據此作進一步的處理，就會產生未提交的數據依賴關係。這種現象被形象的叫做“髒讀”。
　　一句話：事務A讀取到了事務B已經修改但尚未提交的數據，還在這個數據基礎上做了操作。此時，如果B事務回滾，A讀取的數據無效，不符合一致性要求。
　　不可重讀（Non-RepeatableReads）
　　一個事務在讀取某些數據後的某個時間，再次讀取以前讀過的數據，卻發現其讀出的數據已經發生了改變、或某些記錄已經被刪除了！這種現象就叫做“不可重複讀”。
　　一句話：事務A讀取到了事務B已經提交的修改數據，不符合隔離性
　　幻讀（Phantom Reads）
　　一個事務按相同的查詢條件重新讀取以前檢索過的數據，卻發現其他事務插入了滿足其查詢條件的新數據，這種現象就稱爲“幻讀”。
　　一句話：事務A讀取到了事務B提交的新增數據，不符合隔離性。

事務隔離級別

　　"髒讀”、“不可重複讀”和“幻讀”，其實都是數據庫讀一致性問題，必須由數據庫提供一定的事務隔離機制來解決。

隔離級別	髒讀（Dirty Read）	不可重複讀（NonRepeatable Read）	幻讀（Pbantom Read）
讀未提交（Read uncommitted）	可能	可能	可能
讀已提交（Read committed）	不可能	可能	可能
可重複讀（Repeatable Read）	不可能	不可能	可能
可串行化（Serializable）	不可能	不可能	不可能

　　數據庫的事務隔離越嚴格，併發副作用越小，但付出的代價也就越大，因爲事務隔離實質上就是使事務在一定程度上“串行化”進行，這顯然與“併發”是矛盾的。
　　同時，不同的應用對讀一致性和事務隔離程度的要求也是不同的，比如許多應用對“不可重複讀"和“幻讀”並不敏感，可能更關心數據併發訪問的能力。

　　查看當前數據庫的事務隔離級別: show variables like 'tx_isolation';

　　設置事務隔離級別：set tx_isolation = 'REPEATABLE-READ'; （MySQL的數據庫隔離級別：可重複讀）

2.2.2 行鎖與隔離級別案例分析

示例表：

CREATE TABLE `account` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`balance` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `account` (`name`, `balance`) VALUES ('lilei', '450');
INSERT INTO `account` (`name`, `balance`) VALUES ('hanmei','16000');
INSERT INTO `account` (`name`, `balance`) VALUES ('lucy', '2400');

（1）行鎖演示
一個session開啓事務更新不提交，另一個session更新同一條記錄會阻塞，更新不同記錄不會阻塞；

（2）讀未提交：
<a> 開啓事務A，並設置當前事務模式爲 read uncommitted（讀未提交），查詢表account的初始值；set tx_isolation='read-uncommitted';

在事務A的事務提交之前，開啓事務B，更新表account；

<c> 在事務A中，查詢表數據，雖然事務B還沒提交，但是事務A就可以查詢到事務B更新的數據：

<d> 一旦事務B因爲某種原因回滾，事務B所有的操作都將會被撤銷，那事務B查詢到的數據其實就是髒數據：

（3）讀已提交

<a> 開啓事務A，並設置當前事務模式爲 read committed（讀已提交），查詢表account的所有記錄； set tx_isolation='read-committed';

在事務A的事務提交之前，打開另一個事務B，更新表account（update account set balance = balance - 50 where id = 1）；

<c> 這時，事務B的事務還沒提交，事務A去查詢 account 的數據（select * from account），不能查詢到B已經更新的數據，解決了髒讀問題；

<d> 現在將事務B的事務提交了，事務A在去查詢數據（select * from account），結果與上一步不一致，即產生了不可重複讀的問題；

（4）可重複讀

<a> 開啓事務A，並設置當前事務模式爲 ’repeatable read‘，查詢表account的所有記錄（select * from account）；set tx_isolation='repeatable-read';

在事務A的事務提交之前，開啓另一個事務B，更新表 account 並提交（update account set balance = balance - 50 where id = 1）；

<c> 在事務A查詢表 account 的所有記錄，與步驟 <a> 查詢結果一致，解決了不可重複讀的問題；

<d> 在事務A，接着執行update account set balance = balance - 50 where id = 1，balance沒有變成 400-50=350，lilei 的 balance 值用的是步驟 中的350來算的，所以是300，數據的一致性倒是沒有被破壞。可重複讀的隔離級別下使用了MVCC(multi-version concurrency control)機制，select操作不會更新版本號，是快照讀（歷史版本）；insert、update和delete會更新版本號，是當前讀（當前版本）

在可重複讀隔離級別，MySQL會有一個 MVCC（多版本併發控制） 機制，它爲了在事務併發的時候能夠提高性能；

可以簡單的理解：在事務開啓的時候，查詢就會生成一個快照，這個快照只在當前的事務有效，其他事務是讀不到這個快照的，該事務提交之前每次讀得都是第一次生成的快照；但是當該事務update的時候，是在已經提交的最後一次數據基礎上更新的；

id	name	balance	創建事務ID	修改事務ID
1	zhangsan	400	5
2	lisi	12000	6	7
3	wangwu	1500	5

2	lisi	12000	7

對於刪除操作，mysql底層會記錄好被刪除的數據行的刪除事務id，對於更新操作mysql底層會新增一行相同數據並記錄好對應的創建事務id在id爲12的事務裏執行查詢操作mysql底層會帶上過濾條件，創建事務id <=max(當前事務id(12)，快照點已提交最大事務id），刪除事務id>max(當前事務id(12)，快照點已提交最大事務id）

注意：begin/start transaction 命令並不是一個事務的起點，在執行到它們之後的第一個操作InnoDB 表的語句，事務才真正啓動，纔會向mysql申請事務id，mysql內部是嚴格按照事務的啓動順序來分配事務id的

（5）幻讀
<a> 開啓事務A，然後查詢一下 account 的數據；

開啓事務B，向表裏插入一條記錄，接着提交事務；

<c> 在事務A中，執行 update 的操作，然後再去表裏查詢，發現數據多了一條出來；

（6）串行化

設置事務的隔離級別：set tx_isolation='serializable';

串行化：上一個事務提交之後，下一個事務才能操作，針對的是整個數據庫；

mysql中事務隔離級別爲serializable時會鎖表，因此不會出現幻讀的情況，這種隔離級別併發性極低，開發中很少會用到。

問題：Mysql默認級別是 repeatable-read，有辦法解決幻讀問題嗎？

答案：間隙鎖在某些情況下可以解決幻讀問題；

間隙鎖

間隙鎖，它封鎖索引記錄中的間隔。

對於以下表中的主鍵ID，id 在 3 ~ 8 就是一個間隙，id 在 10 ~ 20 是一個間隙，id 在 20 ~ 正無窮是一個間隙；

在事務A中執行 update account set name ='wangt' where id > 10 and id <=20; 執行這個SQL語句就會將 10 ~ 20 這個間隙鎖住，這個時候去在另外一個事務B中去插入 id = 18 的記錄，則插入不進去的；這樣可以間接的解決幻讀的問題；

無索引行鎖會升級爲表鎖

鎖主要是加在索引上，如果對非索引字段更新, 行鎖可能會變表鎖；

例如，在 session1 中執行 update account set balance = 800 where name = 'lilei'; 在 session2 中對 account 表任意一行做操作，都會阻塞住；

InnoDB的行鎖是針對索引加的鎖，不是針對記錄加的鎖。並且該索引不能失效，否則都會從行鎖升級爲表鎖；

鎖定某一行還可以用 lock in share mode(共享鎖) 或 for update(排它鎖)，例如：select * from test_innodb_lock where a = 2 for update;這樣其他session只能讀這行數據，修改則會被阻塞，直到鎖定行的session提交;

2.2.3 結論

　　Innodb存儲引擎由於實現了行級鎖定，雖然在鎖定機制的實現方面所帶來的性能損耗可能比表級鎖定會要更高一下，但是在整體併發處理能力方面要遠遠優於MYISAM的表級鎖定的。當系統併發量高的時候，Innodb的整體性能和MYISAM相比就會有比較明顯的優勢了。

　　但是，Innodb的行級鎖定同樣也有其脆弱的一面，當我們使用不當的時候，可能會讓Innodb的整體性能表現不僅不能比MYISAM高，甚至可能會更差。

2.2.4 行鎖分析

通過檢查 InnoDB_row_lock 狀態變量來分析系統上的行鎖的爭奪情況 show status like'innodb_row_lock%';
對各個狀態量的說明如下：
Innodb_row_lock_current_waits: 當前正在等待鎖定的數量
Innodb_row_lock_time: 從系統啓動到現在鎖定總時間長度
Innodb_row_lock_time_avg: 每次等待所花平均時間
Innodb_row_lock_time_max：從系統啓動到現在等待最長的一次所花時間
Innodb_row_lock_waits:系統啓動後到現在總共等待的次數

對於這5個狀態變量，比較重要的主要是：
Innodb_row_lock_time_avg （等待平均時長）
Innodb_row_lock_waits （等待總次數）
Innodb_row_lock_time（等待總時長）
尤其是當等待次數很高，而且每次等待時長也不小的時候，我們就需要分析系統中爲什麼會有如此多的等待，然後根據分析結果着手製定優化計劃。

2.2.5 死鎖

死鎖的產生

<a> 在 session1 中開啓事務A，執行：select * from account where id=1 for update;

在session2 中開啓事務B，執行：select * from account where id=2 for update;

<c> 在 session1 中執行：select * from account where id=2 for update; 會阻塞住；

<d> 在 session2 中執行：select * from account where id=1 for update; 會產生死鎖；

MySql在有些情況下會自動檢查死鎖，若檢查到死鎖就會默認執行 rollback；

查看近期死鎖日誌信息：show engine innodb status;
大多數情況mysql可以自動檢測死鎖並回滾產生死鎖的那個事務，但是有些情況mysql沒法自動檢測死鎖

2.2.6 優化建議

儘可能讓所有數據檢索都通過索引來完成，避免無索引行鎖升級爲表鎖；
合理設計索引，儘量縮小鎖的範圍；
儘可能減少檢索條件範圍，避免間隙鎖；
儘量控制事務大小，減少鎖定資源量和時間長度，涉及事務加鎖的sql；
儘量放在事務最後執行；
儘可能低級別事務隔離；

深入理解MySQL鎖與事務隔離級別

1、鎖定義

2、鎖分類

2.1 表鎖

2.2 行鎖

2.2.1 行鎖支持事務

2.2.2 行鎖與隔離級別案例分析

2.2.3 結論

2.2.4 行鎖分析

2.2.5 死鎖

2.2.6 優化建議

認知提升的方法

螞蟻面試：Springcloud核心組件的底層原理，你知道多少？

JS中的if和else的用法以及基礎語法

MySQL的四種事務隔離級別

深入理解MySQL鎖與事務隔離級別

javaScript中數據類型和數組的案例

javaScript數組定義及詳解

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結