資料庫中的鎖機制是預設在內部執行的機制。使用者是了解這一機制，更好的支援後續的操作。
從效率的角度考慮：
1. 2個事務併發訪問同一張表，2個都做查詢，沒必要互斥
2. 2個事務併發訪問同一張表，1個查詢，1個更新，是否有必要互斥，看具體應用場景
例子1：共享單車站點可用車查詢-沒必要互斥
例子2：秒殺-有必要互斥
3. 2個事務併發訪問同一張表，2個都執行更新操作，有必要互斥的
不加鎖的操作：和任何的鎖都不互斥
共享鎖(讀鎖)：所有加共享鎖的操作彼此之間不互斥
排他鎖(寫鎖)：和所有的加鎖操作有互斥
非serlizable級別：查詢不加任何鎖
serlizable級別：查詢加共享鎖
所有的級別下：更新(增刪改)加排他鎖
a(非ser) b(非ser) 是否互斥 原因
讀 讀 不互斥 a和b都不加鎖
讀 寫 不互斥 a不加鎖 b排他鎖
寫 讀 不互斥 a排他鎖 b不加鎖
寫 寫 互斥 a排他鎖 b排他鎖
a(ser) b(非ser) 是否互斥 原因
讀 讀 不互斥 a共享鎖 b不加鎖
寫 讀 不互斥 a排他鎖 b不加鎖
讀 寫 互斥 a共享鎖 b排他鎖
寫 寫 互斥 a排他鎖 b排他鎖
a(ser) b(ser) 是否互斥 原因
讀 讀 不互斥 a共享鎖 b共享鎖
寫 讀 互斥 a排他鎖 b共享鎖
讀 寫 互斥 a共享鎖 b排他鎖
寫 寫 互斥 a排他鎖 b排他鎖
併發的2個事務基於同乙個查詢結果對資料庫進行更新操作，後提交的事務忽略了先提交的事務對資料庫造成的影響，因此造成的問題稱為「更新丟失」。
更新丟失的解決方案：
資料庫如果使用serializable級別，可以天然防止更新丟失，但是對業務的執行效率會有較大的影響。
樂觀鎖解決方案：樂觀鎖樂觀的認為，查詢不會造成更新丟失，所以在查詢環節不做控制。會在更新環節，驗證自己查詢到的結果是否依舊有效。
樂觀鎖解決方案需要乙個第三方標識的支援，可以是第三方資料版本id，或者是最後一次操作的時間戳等
樂觀鎖在執行查詢時，會同時查詢對應的版本id或時間戳
在更新時，會先驗證之前查詢到的版本id或時間戳是否依舊有效
如果有效，則繼續執行更新操作，如果無效，則重新執行最初的查詢操作。
悲觀鎖和樂觀鎖的利弊：
悲觀鎖實現方案簡單，但是在查詢階段加排他鎖會影響併發查詢的效率
樂觀鎖不會影響併發查詢的效率，但是在更新階段需要重新驗證，並且失敗後需要不斷重試
如果當前業務的查詢多，更新少，優先使用樂觀鎖
如果當前業務的查詢少，更新多，優先使用悲觀鎖
提問：更新選單資訊的時候，在頁面上選擇了乙個父選單，在業務層更新方法中，是否需要先驗證一下parentid是否存在？
MySQL資料庫的鎖機制
原文首發於 本文出自 rebornchang的部落格 拋開資料庫引擎說資料庫鎖機制的都是流氓 引言 mysql資料庫的引擎分為三種，myisam isam innodb以及memory，具體的引擎型別效能比較可以baidu到，這裡就不多說了，本文中所說的鎖機制基於innodb引擎，那為啥說基於inn...
Mysql資料庫的鎖機制
鎖機制 當客戶端操作表 記錄 時，為了保證操作的隔離性 多個客戶端操作不能相互影響 通過加鎖來處理。操作方面 讀鎖 讀操作時增加的鎖，也叫共享鎖，s lock。特徵是所有人都只可以讀，只有釋放鎖之後才可以寫。寫鎖 寫操作時增加的鎖，也叫獨佔鎖或排他鎖，x lock。特徵，只有鎖表的客戶可以操作 讀寫...
MySQL資料庫的鎖機制
在併發訪問情況下，很有可能出現不可重複讀等等讀現象。為了更好的應對高併發，封鎖 時間戳 樂觀併發控制 樂觀鎖 悲觀併發控制 悲觀鎖 都是併發控制採用的主要技術方式。按操作劃分 dml鎖，ddl鎖 按鎖的粒度劃分 表級鎖 行級鎖 頁級鎖 按鎖級別劃分 共享鎖 排他鎖 按加鎖方式劃分 自動鎖 顯示鎖 按...