阿里P8架構師談：MySQL行鎖、表鎖、悲觀鎖、樂觀鎖的特點與應用
我們在操作資料庫的時候，可能會由於併發問題而引起的資料的不一致性（資料衝突）。如何保證資料併發訪問的一致性、有效性，是所有資料庫必須解決的一個問題，鎖的衝突也是影響資料庫併發訪問效能的一個重要因素，從這一角度來說，鎖對於資料庫而言就顯得尤為重要。
SQL/">MySQL鎖概述
相對其他資料庫而言，MySQL的鎖機制比較簡單，其最顯著的特點是不同的儲存引擎支援不同的鎖機制。
比如：
MyISAM和MEMORY儲存引擎採用的是表級鎖（table-level locking）；
InnoDB儲存引擎既支援行級鎖（ row-level locking），也支援表級鎖，但預設情況下是採用行級鎖。
MySQL主要的兩種鎖的特性可大致歸納如下:
表級鎖： 開銷小，加鎖快；不會出現死鎖(因為MyISAM會一次性獲得SQL所需的全部鎖)；鎖定粒度大，發生鎖衝突的概率最高,併發度最低。
行級鎖： 開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低,併發度也最高。
頁鎖：開銷和加鎖速度介於表鎖和行鎖之間；會出現死鎖；鎖定粒度介於表鎖和行鎖之間，併發度一般
行鎖 和 表鎖
1. 主要是針對鎖粒度劃分的，一般分為： 行鎖、表鎖、庫鎖
（1）行鎖：訪問資料庫的時候，鎖定整個行資料，防止併發錯誤。
（2）表鎖：訪問資料庫的時候，鎖定整個表資料，防止併發錯誤。
2.行鎖 和 表鎖 的區別：
表鎖 ： 開銷小，加鎖快，不會出現死鎖；鎖定力度大，發生鎖衝突概率高，併發度最低
行鎖 ： 開銷大，加鎖慢， 會出現死鎖 ；鎖定粒度小，發生鎖衝突的概率低，併發度高
悲觀鎖 和 樂觀鎖
（1）悲觀鎖： 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以 每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。
傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
（2）樂觀鎖： 顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在 更新的時候會判斷一下 在此期間別人有沒有去更新這個資料，可以使用版本號等機制。
樂觀鎖適用於多讀的應用型別，這樣可以提高吞吐量 ，像資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。
（3）悲觀鎖 和 樂觀鎖的區別：
兩種鎖各有優缺點，不可認為一種好於另一種，像 樂觀鎖適用於寫比較少的情況下 ，即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但 如果經常產生衝突 ，上層應用會不斷的進行retry，這樣反倒是降低了效能， 所以這種情況下用悲觀鎖就比較合適 。
共享鎖
共享鎖指的就是對於多個不同的事務，對同一個資源共享同一個鎖。相當於對於同一把門，它擁有多個鑰匙一樣。就像這樣，你家有一個大門，大門的鑰匙有好幾把，你有一把，你女朋友有一把，你們都可能通過這把鑰匙進入你們家，這個就是所謂的共享鎖。
剛剛說了，對於悲觀鎖，一般資料庫已經實現了， 共享鎖也屬於悲觀鎖的一種 ，那麼共享鎖在mysql中是通過什麼命令來呼叫呢。通過查詢資料，瞭解到通過在執行語句後面加上 lock in share mode 就代表對某些資源加上共享鎖了。
什麼時候使用表鎖
對於InnoDB表，在絕大部分情況下都應該使用行級鎖，因為事務和行鎖往往是我們之所以選擇InnoDB表的理由。但在個別特殊事務中，也可以考慮使用表級鎖。
第一種情況是：事務需要更新大部分或全部資料，表又比較大，如果使用預設的行鎖，不僅這個事務執行效率低，而且可能造成其他事務長時間鎖等待和鎖衝突，這種情況下可以考慮使用表鎖來提高該事務的執行速度。
第二種情況是：事務涉及多個表，比較複雜，很可能引起死鎖，造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的表，從而避免死鎖、減少資料庫因事務回滾帶來的開銷。
當然，應用中這兩種事務不能太多，否則，就應該考慮使用MyISAM表了。
表鎖和行鎖應用場景：
表級鎖使用與併發性不高，以查詢為主，少量更新的應用 ，比如小型的web應用；
而 行級鎖適用於高併發環境下，對事務完整性要求較高的系統 ，如線上事務處理系統。
以上就是行鎖、表鎖等的特點和應用場景，以下是 最新阿里P8架構師談架構設計系列 。 資料領取方法：加群：855355016
△spring原始碼
△mybatis原始碼
02
分散式架構
隨著我們的業務量越來越大和越重要，單體的架構模式已經無法對應大規模的應用場景，而且系統中決不能存在單點故障導致整體不可用，所以只有垂直或是水平拆分業務系統，使其形成一個分散式的架構，利用分散式架構來冗餘系統消除單點的故障，從而提高整個系統的可用性。同時分散式系統的模組重用度更高，速度更快，擴充套件性更高是大型的專案必不可少的環節。
03
微服務
關於微服務架構的取捨
在合適的專案，合適的團隊，採用微服務架構收益會大於成本。微服務架構有很多吸引人的地方，但在擁抱微服務之前，也需要認清它所帶來的挑戰。需要避免為了“微服務”而“微服務”。微服務架構引入策略 – 對傳統企業而言，開始時可以考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。
04
效能調優
我們不僅僅對專案要運籌帷幄，還要能解決一切效能問題。只有深入學習JVM底層原理，Mysql底層優化以及Tomcat調優，才能達到知其然，知其所以然的效果。除了效能優化之外，也能提供通用的常見思路以及方案選型的考慮點，幫助大家培養在方案選型時的意識、思維以及做各種權衡的能力。
05
開發工具工程化
通過一小段描述資訊來管理專案的構建，報告和文件的軟體專案管理工具。程式員的戰鬥，往往不是一個人的戰鬥，我們如何在一個平臺下高效的去重，進行程式碼review，對功能進行調整，debug，做到在統一的規劃下步步為營，混亂的堆程式碼的過程中找到自己的記錄。這一切都依賴於有效的工具。
06
專案實戰
要想立足於網際網路公司，且能在網際網路浪潮中不被淹沒，對於專案的開發實戰演練是不必可少的技能，也是對自身能力的一個衡量，有多少的量對等於獲得多少的回報。看似簡單的一個專案需求圖譜，其中的底層原理，實現原理又能知道多少？你搭建一個完整的B2C專案平臺到底需要多少知識？這一切都是需要我們考量的。
資料領取方法：加群：855355016