淺談資料庫鎖機制：（只是本人的一些瞭解，個人觀點）
首先：需要明確鎖的分類
鎖包括行級鎖、表級鎖、悲觀鎖、樂觀鎖
首先行級鎖：又叫排他鎖，多見於支援高併發的資料庫搜尋引擎中出現使用，如mysql中的innodb預設是行級鎖；在以下查詢中oracle中會自動應用行級鎖。釋放行級鎖時使用commit或者rollback釋放
SELECT … FOR UPDATE； |
特點:鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高。
表級鎖又分為以下五種：
行共享 (ROW SHARE) – 禁止排他鎖定表，與行排他類似，區別是別的事務還可以在此表上加任何排他鎖。（除排他（exclusive）外）
行排他(ROW EXCLUSIVE) – 禁止使用排他鎖和共享鎖，其他事務依然可以併發地對相同資料表執行查詢，插入，更新，刪除操作，或對錶內資料行加鎖的操作，但不能有其他的排他鎖（自身是可以的，沒發現有什麼用）
共享鎖(SHARE) - 鎖定表，對記錄只讀不寫，多個使用者可以同時在同一個表上應用此鎖，在表沒有被任何DML操作時，多個事務都可加鎖，但只有在僅一個事務加鎖的情況下只有此事務才能對錶更新；當表已經被更新或者指定要更新時（select for update），任何事務都不能加此鎖了。
共享行排他(SHARE ROW EXCLUSIVE) – 比共享鎖更多的限制，禁止使用共享鎖及更高的鎖，在表沒有被任何DML操作時，只有一個事務可以加鎖，可以更新，書上說別的事務可以使用select for update鎖定選中的資料行，可是實驗後沒被驗證。
排他(EXCLUSIVE) – 限制最強的表鎖，僅允許其他使用者查詢該表的行。禁止修改和鎖定表
行級鎖支援高併發，但是鎖的粒度細緻，對系統的開銷比較大，影響效能，也會出現死鎖；表級鎖不會出現死鎖，但是併發時代價高。
悲觀鎖：事務每次去操作資料的時候都假設有其他事務會修改需要訪問的資料，所以在訪問之前都要求上鎖，如：行鎖，表鎖，讀鎖，寫鎖等，都是在做操作之前先上鎖，在整個資料處理過程中，資料將處於鎖定狀態。
樂觀鎖：訪問之前不要求上鎖，只是在進行更新修改操作的時候判斷一下在訪問的期間有沒有其他人在修改資料。它適用於多讀的應用型別，衝突真的發生比較少的時候就比較好，這樣省去了開銷的開銷，可以提高吞吐量;但如果是真的經常要發生衝突的，那每次還要去判斷進行retry,反倒降低的效能，這個時候悲歡鎖比較好。資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖