樂觀鎖
在關系數據庫管理系統里，樂觀並發控制（又名”樂觀鎖”，Optimistic Concurrency Control，縮寫”OCC”）是一種並發控制的方法。它假設多用戶並發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的 那部分數據。在提交數據更新之前，每個事務會先檢查在該事務讀取數據后，有沒有其他事務又修改了該數據。如果其他事務有更新的話，正在提交的事務會進行回 滾。樂觀事務控制最早是由孔祥重（H.T.Kung）教授提出。
樂觀並發控制的階段
樂觀並發控制的事務包括以下階段：
1. 讀取：事務將數據讀入緩存，這時系統會給事務分派一個時間戳。
2. 校驗：事務執行完畢后，進行提交。這時同步校驗所有事務，如果事務所讀取的數據在讀取之后又被其他事務修改，則產生沖突，事務被中斷回滾。
3. 寫入：通過校驗階段后，將更新的數據寫入數據庫。
樂觀並發控制多數用於數據爭用不大、沖突較少的環境中，這種環境中，偶爾回滾事務的成本會低於讀取數據時鎖定數據的成本，因此可以獲得比其他並發控制方法更高的吞吐量。
相對於悲觀鎖，在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄數據版本。
數據版本,為數據增加的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次，同時對版本標識進行更新。當我們提交更新的時候，判 斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，如果數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，否則認為是過 期數據。
實現數據版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。 使用版本號實現樂觀鎖
使用版本號時，可以在數據初始化時指定一個版本號，每次對數據的更新操作都對版本號執行+1操作。並判斷當前版本號是不是該數據的最新的版本號。
使用版本號實現樂觀鎖
使用版本號時，可以在數據初始化時指定一個版本號，每次對數據的更新操作都對版本號執行+1操作。並判斷當前版本號是不是該數據的最新的版本號。
1.查詢出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根據商品信息生成訂單
3.修改商品status為2
update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};
優點與不足
樂觀並發控制相信事務之間的數據競爭(data race)的概率是比較小的，因此盡可能直接做下去，直到提交的時候才去鎖定，所以不會產生任何鎖和死鎖。但如果直接簡單這么做，還是有可能會遇到不可預 期的結果，例如兩個事務都讀取了數據庫的某一行，經過修改以后寫回數據庫，這時就遇到了問題。
悲觀鎖
在關系數據庫管理系統里，悲觀並發控制（又名”悲觀鎖”，Pessimistic Concurrency Control，縮寫”PCC”）是一種並發控制的方法。它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作讀某行數據應用了 鎖，那只有當這個事務把鎖釋放，其他事務才能夠執行與該鎖沖突的操作。
悲觀並發控制主要用於數據爭用激烈的環境，以及發生並發沖突時使用鎖保護數據的成本要低於回滾事務的成本的環境中。
使用
MySQL InnoDB中使用悲觀鎖
要使用悲觀鎖，我們必須關閉mysql數據庫的自動提交屬性，因為MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作后，MySQL會立刻將結果進行提交。set autocommit=0;
#0.開始事務 begin;/begin work;/start transaction; (三者選一就可以) #1.查詢出商品信息 select status from t_goods where id=1 for update; #2.根據商品信息生成訂單 insert into t_orders (id,goods_id) values (null,1); #3.修改商品status為2 update t_goods set status=2; #4.提交事務 commit;/commit work;
上面的查詢語句中，我們使用了select…for update的方式，這樣就通過開啟排他鎖的方式實現了悲觀鎖。此時在t_goods表中，id為1的 那條數據就被我們鎖定了，其它的事務必須等本次事務提交之后才能執行。這樣我們可以保證當前的數據不會被其它事務修改。
上面我們提到，使用select…for update會把數據給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認行級鎖。行級鎖都是基於索引的，如果一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住，這點需要注意。
優點與不足
悲觀並發控制實際上是”先取鎖再訪問”的保守策略，為數據處理的安全提供了保證。但是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增 加產生死鎖的機會；另外，在只讀型事務處理中由於不會產生沖突，也沒必要使用鎖，這樣做只能增加系統負載；還有會降低了並行性，一個事務如果鎖定了某行數 據，其他事務就必須等待該事務處理完才可以處理那行數
總結
樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，像數據庫如果提供類似於write_condition機智的其實都是提供的樂觀鎖。 相反，如果經常發生沖突，上層應用會不斷進行 retry，這樣反而降低了性能，所以這種情況下用悲觀鎖比較合適
---------------------------------------第二種理解-------------------
樂觀鎖
樂觀鎖不是數據庫自帶的，需要我們自己去實現。樂觀鎖是指操作數據庫時(更新操作)，想法很樂觀，認為這次的操作不會導致沖突，在操作數據時，並不進行任何其他的特殊處理（也就是不加鎖），而在進行更新后，再去判斷是否有沖突了。
通常實現是這樣的：在表中的數據進行操作時(更新)，先給數據表加一個版本(version)字段，每操作一次，將那條記錄的版本號加1。也就是先查詢出那條記錄，獲取出version字段,如果要對那條記錄進行操作(更新),則先判斷此刻version的值是否與剛剛查詢出來時的version的值相等，如果相等，則說明這段期間，沒有其他程序對其進行操作，則可以執行更新，將version字段的值加1；如果更新時發現此刻的version值與剛剛獲取出來的version的值不相等，則說明這段期間已經有其他程序對其進行操作了，則不進行更新操作。
舉例：
下單操作包括3步驟：
1.查詢出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根據商品信息生成訂單
3.修改商品status為2
update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};
除了自己手動實現樂觀鎖之外，現在網上許多框架已經封裝好了樂觀鎖的實現，如hibernate，需要時，可能自行搜索"hiberate 樂觀鎖"試試看。
悲觀鎖
與樂觀鎖相對應的就是悲觀鎖了。悲觀鎖就是在操作數據時，認為此操作會出現數據沖突，所以在進行每次操作時都要通過獲取鎖才能進行對相同數據的操作，這點跟java中的synchronized很相似，所以悲觀鎖需要耗費較多的時間。另外與樂觀鎖相對應的，悲觀鎖是由數據庫自己實現了的，要用的時候，我們直接調用數據庫的相關語句就可以了。
說到這里，由悲觀鎖涉及到的另外兩個鎖概念就出來了，它們就是共享鎖與排它鎖。共享鎖和排它鎖是悲觀鎖的不同的實現，它倆都屬於悲觀鎖的范疇。
共享鎖
begin; SELECT * from city where id = "1" lock in share mode;
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction
排它鎖
行鎖
行鎖，由字面意思理解，就是給某一行加上鎖，也就是一條記錄加上鎖。
比如之前演示的共享鎖語句
SELECT * from city where id = "1" lock in share mode;
由於對於city表中,id字段為主鍵，就也相當於索引。執行加鎖時，會將id這個索引為1的記錄加上鎖，那么這個鎖就是行鎖。
表鎖
表鎖，和行鎖相對應，給這個表加上鎖。
MyISAM引擎里有的，暫時研究了