MYSQL5.5 樂觀鎖、悲觀鎖、共享鎖、排它鎖、行鎖、表鎖
存儲引擎：innoDB
數據庫鎖的使用場景：
開發中在操作數據庫的時候，可能會由於併發問題而引起的數據的不一致性（數據衝突），事物控制等操作。
樂觀鎖
樂觀鎖不是數據庫自帶的，需要我們自己去實現。樂觀鎖是指操作數據庫時(更新操作)，認爲這次的操作不會導致衝突，在操作數據時，並不進行任何其他的特殊處理（也就是不加鎖），而在進行更新後，再去判斷是否有衝突了。
實踐操作：在表中的數據進行操作時(更新)，先給數據表加一個版本(version)字段，每操作一次，將那條記錄的版本號加1。也就是先查詢出那條記錄，獲取出version字段,如果要對那條記錄進行操作(更新),則先判斷此刻version的值是否與剛剛查詢出來時的version的值相等，如果相等，則說明這段期間，沒有其他程序對其進行操作，則可以執行更新，將version字段的值加1；如果更新時發現此刻的version值與剛剛獲取出來的version的值不相等，則說明這段期間已經有其他程序對其進行操作了，則不進行更新操作。
舉例：
下單操作包括3步驟：
1.查詢出商品信息
select (status,status,version) from goods where id=#{id}
2.根據商品信息生成訂單
insert into order orderNo select id from goods
3.修改商品status爲2
update goods
set status=2,version=version+1
where id=#{id} and version=#{version};
悲觀鎖
與樂觀鎖相對應的就是悲觀鎖了。悲觀鎖就是在操作數據時，認爲此操作會出現數據衝突，所以在進行每次操作時都要通過獲取鎖才能進行對相同數據的操作，這點跟java中的synchronized很相似，所以悲觀鎖需要耗費較多的時間。另外與樂觀鎖相對應的，悲觀鎖是由數據庫自己實現了的，要用的時候，我們直接調用數據庫的相關語句就可以了。
說到這裏，由悲觀鎖涉及到的另外兩個鎖概念就出來了，它們就是共享鎖與排它鎖。共享鎖和排它鎖是悲觀鎖的不同的實現，它倆都屬於悲觀鎖的範疇。
共享鎖
共享鎖指的就是對於多個不同的事務，對同一個資源共享同一個鎖。相當於對於同一把門，它擁有多個鑰匙一樣。就像這樣，你家有一個大門，大門的鑰匙有好幾把，你的家人都可以進入，這個就是所謂的共享鎖。
對於悲觀鎖，一般數據庫已經實現了，共享鎖也屬於悲觀鎖的一種，那麼共享鎖在mysql中是通過什麼命令來調用呢。
通過在執行語句後面加上lock in share mode就代表對某些資源加上共享鎖了。
比如，我這裏通過mysql打開兩個查詢編輯器，在其中開啓一個事務，並不執行commit語句
city表DDL如下：
CREATE TABLE `city` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`state` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=utf8;
begin;
SELECT * from city where id = "1" lock in share mode;
然後在另一個查詢窗口中，對id爲1的數據進行更新
update city set name="666" where id ="1";
此時，操提示錯誤信息
[SQL]update city set name="666" where id ="1";
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction
那麼證明，對於id=1的記錄加鎖成功了，在上一條記錄還沒有commit之前，這條id=1的記錄被鎖住了，只有在上一個事務釋放掉鎖後才能進行操作，或用共享鎖才能對此數據進行操作。
再實驗一下：
update city set name="666" where id ="1" lock in share mode;
[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'lock in share mode' at line 1
加上共享鎖後，也提示錯誤信息了，對於update,insert,delete語句會自動加排它鎖的原因
於是，我又試了試SELECT * from city where id = "1" lock in share mode; 這樣釋放鎖。
排它鎖
排它鎖與共享鎖相對應，就是指對於多個不同的事務，對同一個資源只能有一把鎖。
與共享鎖類型，在需要執行的語句後面加上for update就可以了
行鎖
行鎖，由字面意思理解，就是給某一行加上鎖，也就是一條記錄加上鎖。
比如之前演示的共享鎖語句
SELECT * from city where id = "1" lock in share mode;
由於對於city表中,id字段爲主鍵，就也相當於索引。執行加鎖時，會將id這個索引爲1的記錄加上鎖，那麼這個鎖就是行鎖。
表鎖，和行鎖相對應，給這個表加上鎖。
MySQL表級鎖的鎖模式 存儲引擎 MyISAM
MySQL表級鎖有兩種模式：表共享鎖（Table Read Lock）和表獨佔寫鎖（Table Write Lock）。
對MyISAM的讀操作，不會阻塞其他用戶對同一表請求，但會阻塞對同一表的寫請求；
對MyISAM的寫操作，則會阻塞其他用戶對同一表的讀和寫操作；
MyISAM表的讀操作和寫操作之間，以及寫操作之間是串行的。
當一個線程獲得對一個表的寫鎖後，只有持有鎖線程可以對錶進行更新操作。其他線程的讀、寫操作都會等待，直到鎖被釋放爲止。
表級鎖
存儲引擎myISAM
MySQL的表鎖有兩種模式：表共享讀鎖（Table Read Lock）和表獨佔寫鎖（Table Write Lock）。
對myISAM表的讀操作，不會阻塞其他用戶對同一表的讀請求，但會阻塞對同一表的寫請求；對ＭyISAM表的寫操作，則會阻塞其他用戶對同一表的讀和寫請求；ＭyISAM表的讀和寫操作之間，以及寫和寫操作之間是串行的！（當一線程獲得對一個表的寫鎖後，只有持有鎖的線程可以對錶進行更新操作。其他線程的讀、寫操作都會等待，直到鎖被釋放爲止。）
如何加表鎖
MyISAM在執行查詢語句（SELECT）前，會自動給涉及的所有表加讀鎖，在執行更新操作（UPDATE、DELETE、INSERT等）前，會自動給涉及的表加寫鎖，這個過程並不需要用戶干預，因此用戶一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。在本書的示例中，顯式加鎖基本上都是爲了方便而已，並非必須如此。
給MyISAM表顯示加鎖，一般是爲了一定程度模擬事務操作，實現對某一時間點多個表的一致性讀取。例如，有一個訂單表orders，其中記錄有訂單的總金額total，同時還有一個訂單明細表order_detail，其中記錄有訂單每一產品的金額小計subtotal，假設我們需要檢查這兩個表的金額合計是否相等，可能就需要執行如下兩條SQL：
SELECT SUM(total) FROM orders;
SELECT SUM(subtotal) FROM order_detail;
這時，如果不先給這兩個表加鎖，就可能產生錯誤的結果，因爲第一條語句執行過程中，order_detail表可能已經發生了改變。因此，正確的方法應該是：
LOCK tables orders read local,order_detail read local;
SELECT SUM(total) FROM orders;
SELECT SUM(subtotal) FROM order_detail;
Unlock tables;
要特別說明以下兩點內容。
上面的例子在LOCK TABLES時加了‘local’選項，其作用就是在滿足MyISAM表併發插入條件的情況下，允許其他用戶在表尾插入記錄
在用LOCKTABLES給表顯式加表鎖是時，必須同時取得所有涉及表的鎖，並且MySQL支持鎖升級。
也就是說，在執行LOCK TABLES後，只能訪問顯式加鎖的這些表，不能訪問未加鎖的表；同時，如果加的是讀鎖，那麼只能執行查詢操作，而不能執行更新操作。
其實，在自動加鎖的情況下也基本如此，MySQL問題一次獲得SQL語句所需要的全部鎖。
這也正是MyISAM表不會出現死鎖（Deadlock Free）的原因一個session使用LOCK TABLE 命令給表film_text加了讀鎖，這個session可以查詢鎖定表中的記錄，但更新或訪問其他表都會提示錯誤；同時，另外一個session可以查詢表中的記錄，但更新就會出現鎖等待。
當使用LOCK TABLE時，不僅需要一次鎖定用到的所有表，而且，同一個表在SQL語句中出現多少次，就要通過與SQL語句中相同的別名鎖多少次，否則也會出錯！
併發鎖
在一定條件下，MyISAM也支持查詢和操作的併發進行。
MyISAM存儲引擎有一個系統變量concurrent_insert，專門用以控制其併發插入的行爲，其值分別可以爲0、1或2。
當concurrent_insert設置爲0時，不允許併發插入。
當concurrent_insert設置爲1時，如果MyISAM允許在一個讀表的同時，另一個進程從表尾插入記錄。這也是MySQL的默認設置。
當concurrent_insert設置爲2時，無論MyISAM表中有沒有空洞，都允許在表尾插入記錄，都允許在表尾併發插入記錄。
可以利用MyISAM存儲引擎的併發插入特性，來解決應用中對同一表查詢和插入鎖爭用。例如，將concurrent_insert系統變量爲2，總是允許併發插入；同時，通過定期在系統空閒時段執行OPTIONMIZE TABLE語句來整理空間碎片，收到因刪除記錄而產生的中間空洞。
MyISAM的鎖調度
前面講過，MyISAM存儲引擎的讀和寫鎖是互斥，讀操作是串行的。那麼，一個進程請求某個MyISAM表的讀鎖，同時另一個進程也請求同一表的寫鎖，MySQL如何處理呢？答案是寫進程先獲得鎖。不僅如此，即使讀進程先請求先到鎖等待隊列，寫請求後到，寫鎖也會插到讀請求之前！這是因爲MySQL認爲寫請求一般比讀請求重要。這也正是MyISAM表不太適合於有大量更新操作和查詢操作應用的原因，因爲，大量的更新操作會造成查詢操作很難獲得讀鎖，從而可能永遠阻塞。
通過執行命令SET LOW_PRIORITY_UPDATES=1，使該連接發出的更新請求優先級降低。
通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優先級。
雖然上面3種方法都是要麼更新優先，要麼查詢優先的方法，但還是可以用其來解決查詢相對重要的應用（如用戶登錄系統）中，讀鎖等待嚴重的問題。
另外，MySQL也提供了一種折中的辦法來調節讀寫衝突，即給系統參數max_write_lock_count設置一個合適的值，當一個表的讀鎖達到這個值後，MySQL變暫時將寫請求的優先級降低，給讀進程一定獲得鎖的機會。
上面已經討論了寫優先調度機制和解決辦法。這裏還要強調一點：一些需要長時間運行的查詢操作，也會使寫進程“餓死”！因此，應用中應儘量避免出現長時間運行的查詢操作，不要總想用一條SELECT語句來解決問題。因爲這種看似巧妙的SQL語句，往往比較複雜，執行時間較長，在可能的情況下可以通過使用中間表等措施對SQL語句做一定的“分解”，使每一步查詢都能在較短時間完成，從而減少鎖衝突。如果複雜查詢不可避免，應儘量安排在數據庫空閒時段執行，比如一些定期統計可以安排在夜間執行。