鎖模組之MyISAM與InooDB關於鎖方面的區別

常見問題：

myisam預設使用的是表級鎖，不支援行級鎖

innodbmoren用的是行級鎖，也支援表級鎖

myisam引擎在進行查詢的時候，會自動為表加上乙個讀鎖，而對資料進行增刪改的時候，會為我們操作的表，加上乙個表級別的寫鎖，當讀鎖沒有被釋放，另外乙個session想要對同乙個表加上寫鎖，他就會被堵塞，知道所有的讀鎖被釋放位置。如何顯示的為表加上讀鎖，如下：

釋放鎖：

讀鎖有另外的名字：共享鎖

以下是演示寫鎖，然後在是讀鎖或者寫鎖

然後在另外乙個session中做讀操作

在執行讀操作的時候，由於已經有寫鎖，所以該此讀操作被堵塞。

先執行修改操作（加寫鎖），在另外乙個session中做修改操作（寫鎖），則該寫鎖會被堵塞。

寫鎖的別名：排它鎖

insert、delete、update都可以上排它鎖，對於select也可以上排它鎖，如下：

當select操作上排它鎖之後，其他session中的select也會被堵塞

innodb:

由於innodb支援事務，所以我們可以通過session獲取鎖，再是不提交的方式，模擬併發訪問的過程。mysql是預設提交事務的。

如下模擬兩個session對同一行資料進行修改的情況：

兩個session的修改語句如下：

執行結果發現，並沒有出現第二個session在執行時出現堵塞的情況

innodb使用個是二段鎖，即加鎖和解鎖是分兩個步驟完成的，即先對同乙個事務裡的一批操作分別進行加鎖，然後到commit的時候，在對事務裡加上的鎖進行統一的解鎖，而當前的commit是自動提交的，所以看起來和myisam沒喲太大的區別。

我們可以通過執行以下命令得到結論：

on：代表事務預設是自動提交的。

關閉自動提交（該設定只針對當前的session，而其他session仍然是自動提交的）：

操作驗證如下（前提的首要關閉自動提交）：

1：其中乙個session加上共享鎖，執行如下語句：

2：在另外乙個session中對同一行執行update操作

實驗結果是第二個session中的操作能修改資料成功。

原因如下：

innodb對select進行了改進，第乙個session中的select操作並沒有對該行上鎖，所以才導致更新是成功的。innodb引擎下如何顯示的加共享鎖，如下：

當在另外乙個session中執行update操作的時候就會堵塞

資料庫事務作為乙個單獨的資料庫邏輯單元執行的一系列操作，要麼完全執行，要麼全部都不執行。

acid：

原子性(aotmic)：事務包含的所有操作，要麼全部執行，要麼全部失敗回滾，要麼全做，要麼全都不做

一致性（consistency）：事務因確保資料庫的狀態，從原來的一直狀態，轉變為另外一致的狀態，一致狀態的含義是指：

資料庫中的資料應滿足完整性約束，就好比轉賬，假設使用者a和使用者b加起來的錢總和是2000，不管兩者如何轉賬，事務結束後，兩個使用者的錢相加起來還要是2000，這就是事務的一致性

隔離性（isolation）:多個事務併發執行時，乙個事務的執行，不應該影響其他事務的執行

永續性（durability）：乙個事務一旦提交，他對資料庫的修改，應該永久儲存在資料庫中，永續性意味著當資料庫發生故障時，確保已提交事務的更新不能丟失，即對已提交事務的更新能恢復，一旦乙個事務被提交，dbms必須保證提供適當的冗餘，使其耐得住系統的故障，永續性主要是在於dbms的恢復效能

事務併發訪問引起的問題以及如何避免

即乙個事務的更新覆蓋了另外乙個事務的更新