一、for update的使用場景
如果遇到存在高並發並且對於數據的准確性很有要求的場景，是需要了解和使用for update的。
比如涉及到金錢、庫存等。一般這些操作都是很長一串並且是開啟事務的。如果庫存剛開始讀的時候是1，而立馬另一個進程進行了update將庫存更新為0了，而事務還沒有結束，會將錯的數據一直執行下去，就會有問題。所以需要for upate 進行數據加鎖防止高並發時候數據出錯。
記住一個原則：一鎖二判三更新
1、排他鎖的申請前提
排他鎖的申請前提是需要：沒有其他線程對該結果集中的任何行數據使用排他鎖或共享鎖，否則申請會阻塞。
for update僅適用於InnoDB，且必須在事務塊(BEGIN/COMMIT)中才能生效。在進行事務操作時，通過“for update”語句，MySQL會對查詢結果集中每行數據都添加排他鎖，其他線程對該記錄的更新與刪除操作都會阻塞。
排他鎖包含行鎖、表鎖。
2、數據一致性
假設有A、B兩個用戶同時各購買一件 id=1 的商品，用戶A獲取到的庫存量為 1000，用戶B獲取到的庫存量也為 1000，用戶A完成購買后修改該商品的庫存量為 999，用戶B完成購買后修改該商品的庫存量為 999，此時庫存量數據產生了不一致。
有兩種解決方案。
3、悲觀鎖方案：
每次獲取商品時，對該商品加排他鎖。也就是在用戶A獲取 id=1 的商品信息時對該行記錄加鎖，期間其他用戶阻塞等待訪問該記錄。
悲觀鎖適合寫入頻繁的場景。
begin; select * from goods where id = 1 for update; update goods set stock = stock - 1 where id = 1; commit;
4、樂觀鎖方案：
每次獲取商品時，不對該商品加鎖。在更新數據的時候需要比較程序中的庫存量與數據庫中的庫存量是否相等，如果相等則進行更新，反之程序重新獲取庫存量，再次進行比較，直到兩個庫存量的數值相等才進行數據更新。
樂觀鎖適合讀取頻繁的場景。
// 不加鎖獲取 id=1 的商品對象 select * from goods where id = 1 begin; // 更新 stock 值，這里需要注意 where 條件 “stock = cur_stock”，只有程序中獲取到的庫存量與數據庫中的庫存量相等才執行更新 update goods set stock = stock - 1 where id = 1 and stock = cur_stock; commit;
二、行鎖與表鎖
頁級:引擎 BDB。
表級:引擎 MyISAM ， 理解為鎖住整個表，可以同時讀，寫不行
行級:引擎 INNODB ， 單獨的一行記錄加鎖
表級，直接鎖定整張表，在你鎖定期間，其它進程無法對該表進行寫操作。如果你是寫鎖，則其它進程則讀也不允許
行級，僅對指定的記錄進行加鎖，這樣其它進程還是可以對同一個表中的其它記錄進行操作。
頁級，表級鎖速度快，但沖突多，行級沖突少，但速度慢。所以取了折衷的頁級，一次鎖定相鄰的一組記錄。
InnoDB默認是行級別的鎖，當有明確指定的主鍵時候，是行級鎖，否則是表級別。
for update的注意點：for update 僅適用於InnoDB，並且必須開啟事務，在begin與commit之間才生效。要測試for update的鎖表情況，可以利用MySQL的Command Mode，開啟二個視窗來做測試。
1、只根據主鍵進行查詢，並且查詢到數據，主鍵字段產生行鎖；沒有查詢到數據，不產生鎖。
2、根據主鍵、非主鍵含索引（name）進行查詢，並且查詢到數據，主鍵字段產生行鎖，name字段產生行鎖；沒有查詢到數據，不產生鎖。
3、根據非主鍵含索引（name）進行查詢，並且查詢到數據，name字段產生行鎖；沒有查詢到數據，不產生鎖。
4、只根據主鍵進行查詢，查詢條件為不等於，並且查詢到數據，主鍵字段產生表鎖；沒有查詢到數據，主鍵字段產生表鎖。
5、只根據主鍵進行查詢，查詢條件為 like，並且查詢到數據，主鍵字段產生表鎖；沒有查詢到數據，主鍵字段產生表鎖。
6、根據非主鍵不含索引（stock）進行查詢，並且查詢到數據，stock字段產生表鎖。沒有查詢到數據，stock字段產生表鎖。
總結：
1、InnoDB行鎖是通過給索引上的索引項加鎖來實現的，只有通過索引條件檢索數據，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖。無主鍵或主鍵不明確或無索引，表鎖；明確指定主鍵或索引，且有數據，行鎖；無數據，則無鎖。
2、由於MySQL的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果是使用相同的索引鍵，是會出現鎖沖突的。應用設計的時候要注意這一點。
3、當表有多個索引的時候，不同的事務可以使用不同的索引鎖定不同的行，另外，不論是使用主鍵索引、唯一索引或普通索引，InnoDB都會使用行鎖來對數據加鎖。
4、即便在條件中使用了索引字段，但是否使用索引來檢索數據是由MySQL通過判斷不同執行計划的代價來決定的，如果MySQL認為全表掃描效率更高，比如對一些很小的表，它就不會使用索引，這種情況下InnoDB將使用表鎖，而不是行鎖。因此，在分析鎖沖突時，別忘了檢查SQL的執行計划，以確認是否真正使用了索引。
5、檢索值的數據類型與索引字段不同，雖然MySQL能夠進行數據類型轉換，但卻不會使用索引，從而導致InnoDB使用表鎖。通過用explain檢查兩條SQL的執行計划，我們可以清楚地看到了這一點。
三、悲觀鎖與樂觀鎖
1、悲觀鎖
當要對數據庫中的一條數據進行修改的時候，為了避免同時被其他人修改，最好的辦法就是直接對該數據進行加鎖以防止並發。這種借助數據庫鎖機制，在修改數據之前先鎖定，再修改的方式被稱之為悲觀並發控制【又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫“PCC”】。
悲觀鎖，正如其名，具有強烈的獨占和排他特性。它指的是對數據被外界(包括本系統當前的其他事務，以及來自外部系統的事務處理)修改持保守態度。因此，在整個數據處理過程中，將數據處於鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制(也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據)。
之所以叫做悲觀鎖，是因為這是一種對數據的修改抱有悲觀態度的並發控制方式。我們一般認為數據被並發修改的概率比較大，所以需要在修改之前先加鎖。
悲觀鎖主要分為共享鎖或排他鎖
- 共享鎖【Shared lock】又稱為讀鎖，簡稱S鎖。顧名思義，共享鎖就是多個事務對於同一數據可以共享一把鎖，都能訪問到數據，但是只能讀不能修改。
- 排他鎖【Exclusive lock】又稱為寫鎖，簡稱X鎖。顧名思義，排他鎖就是不能與其他鎖並存，如果一個事務獲取了一個數據行的排他鎖，其他事務就不能再獲取該行的其他鎖，包括共享鎖和排他鎖，但是獲取排他鎖的事務是可以對數據行讀取和修改。
悲觀並發控制實際上是“先取鎖再訪問”的保守策略，為數據處理的安全提供了保證。
但是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增加產生死鎖的機會。另外還會降低並行性，一個事務如果鎖定了某行數據，其他事務就必須等待該事務處理完才可以處理那行數據。
2、樂觀鎖
樂觀鎖是相對悲觀鎖而言的，樂觀鎖假設數據一般情況下不會造成沖突，所以在數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測，如果發現沖突了，則返回給用戶錯誤的信息，讓用戶決定如何去做。
樂觀鎖機制采取了更加寬松的加鎖機制。樂觀鎖是相對悲觀鎖而言，也是為了避免數據庫幻讀、業務處理時間過長等原因引起數據處理錯誤的一種機制，但樂觀鎖不會刻意使用數據庫本身的鎖機制，而是依據數據本身來保證數據的正確性。
相對於悲觀鎖，在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄數據版本。
樂觀並發控制相信事務之間的數據競爭(data race)的概率是比較小的，因此盡可能直接做下去，直到提交的時候才去鎖定，所以不會產生任何鎖和死鎖。
3、悲觀鎖實現方式
悲觀鎖的實現，往往依靠數據庫提供的鎖機制。在數據庫中，悲觀鎖的流程如下：
- 在對記錄進行修改前，先嘗試為該記錄加上排他鎖(exclusive locking)。
- 如果加鎖失敗，說明該記錄正在被修改，那么當前查詢可能要等待或者拋出異常。具體響應方式由開發者根據實際需要決定。
- 如果成功加鎖，那么就可以對記錄做修改，事務完成后就會解鎖了。
- 期間如果有其他對該記錄做修改或加排他鎖的操作，都會等待解鎖或直接拋出異常。
拿比較常用的MySql Innodb引擎舉例，來說明一下在SQL中如何使用悲觀鎖。
要使用悲觀鎖，必須關閉MySQL數據庫的自動提交屬性。因為MySQL默認使用autocommit模式，也就是說，當執行一個更新操作后，MySQL會立刻將結果進行提交。(sql語句：set autocommit=0)
以電商下單扣減庫存的過程說明一下悲觀鎖的使用：
以上，在對id = 1的記錄修改前，先通過for update的方式進行加鎖，然后再進行修改。這就是比較典型的悲觀鎖策略。
如果以上修改庫存的代碼發生並發，同一時間只有一個線程可以開啟事務並獲得id=1的鎖，其它的事務必須等本次事務提交之后才能執行。這樣可以保證當前的數據不會被其它事務修改。
上面提到，使用select…for update會把數據給鎖住，不過需要注意一些鎖的級別，MySQL InnoDB默認行級鎖。行級鎖都是基於索引的，如果一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住，這點需要注意。
使用樂觀鎖就不需要借助數據庫的鎖機制了。樂觀鎖的概念中其實已經闡述了它的具體實現細節。主要就是兩個步驟：沖突檢測和數據更新。
其實現方式有一種比較典型的就是CAS(Compare and Swap)。CAS是項樂觀鎖技術，當多個線程嘗試使用CAS同時更新同一個變量時，只有其中一個線程能更新變量的值，而其它線程都失敗，失敗的線程並不會被掛起，而是被告知這次競爭中失敗，並可以再次嘗試。
比如前面的扣減庫存問題，通過樂觀鎖可以實現如下：
以上，在更新之前，先查詢一下庫存表中當前庫存數(quantity)，然后在做update的時候，以庫存數作為一個修改條件。當提交更新的時候，判斷數據庫表對應記錄的當前庫存數與第一次取出來的庫存數進行比對，如果數據庫表當前庫存數與第一次取出來的庫存數相等，則予以更新，否則認為是過期數據。
以上更新語句存在一個比較重要的問題，即傳說中的ABA問題。比如說一個線程one從數據庫中取出庫存數3，這時候另一個線程two也從數據庫中取出庫存數3，並且two進行了一些操作變成了2，然后two又將庫存數變成3，這時候線程one進行CAS操作發現數據庫中仍然是3，然后one操作成功。盡管線程one的CAS操作成功，但是不代表這個過程就是沒有問題的。
有一個比較好的辦法可以解決ABA問題，那就是通過一個單獨的可以順序遞增的version字段。改為以下方式即可：
樂觀鎖每次在執行數據的修改操作時，都會帶上一個版本號，一旦版本號和數據的版本號一致就可以執行修改操作並對版本號執行+1操作，否則就執行失敗。因為每次操作的版本號都會隨之增加，所以不會出現ABA問題，因為版本號只會增加不會減少。
除了version以外，還可以使用時間戳，因為時間戳天然具有順序遞增性。
以上SQL其實還是有一定的問題的，就是一旦遇上高並發的時候，就只有一個線程可以修改成功，那么就會存在大量的失敗。對於像淘寶這樣的電商網站，高並發是常有的事，總讓用戶感知到失敗顯然是不合理的。所以，還是要想辦法減少樂觀鎖的粒度的。有一條比較好的建議，可以減小樂觀鎖力度，最大程度的提升吞吐率，提高並發能力！如下：
以上SQL語句中，如果用戶下單數為1，則通過quantity - 1 > 0的方式進行樂觀鎖控制。以上update語句，在執行過程中，會在一次原子操作中自己查詢一遍quantity的值，並將其扣減掉1。
高並發環境下鎖粒度把控是一門重要的學問，選擇一個好的鎖，在保證數據安全的情況下，可以大大提升吞吐率，進而提升性能。
在樂觀鎖與悲觀鎖的選擇上面，主要看下兩者的區別以及適用場景就可以了。
- 樂觀鎖並未真正加鎖，效率高。一旦鎖的粒度掌握不好，更新失敗的概率就會比較高，容易發生業務失敗。
- 悲觀鎖依賴數據庫鎖，效率低。更新失敗的概率比較低。
隨着互聯網三高架構（高並發、高性能、高可用）的提出，悲觀鎖已經越來越少的被應用到生產環境中了，尤其是並發量比較大的業務場景。