MySql鎖與InnoDB引擎

MySql鎖與InnoDB引擎

mysql的鎖是面試中很高頻問題，也是咱們在平常開發中常常會遇到可是咱們並無注意到的地方。我把我本身理解的鎖經過本篇博文分享出來，因爲鎖須要結合事務來理解，本文只介紹鎖的基本概念，一樣爲了理解事務會更加深入，先介紹了InnoDB的一些基礎概念，也是記錄本身的學習，歡迎你們一塊兒探討交流。

下一篇：mysql的事務與mvcc

鎖的分類：

• 按照鎖的粒度來分

  • 全局鎖: 鎖的是整個database，類比一個庫爲一棟大樓，那此時就是鎖的整棟樓的大門
  • 表級鎖： 鎖的是某個table，類比一個表爲大樓的某一層，此時鎖的就是某一層整層
  • 行級鎖：鎖的是某一行數據，類比每行鎖的是某一層的某一間房間，此時鎖的是某一個房間

• 表鎖和行鎖的區別

  • 表級鎖，開銷大，加鎖快，不會出現死鎖。鎖的粒度大。併發度低。
  • 行級鎖，開銷小，加鎖慢，會出現死鎖，鎖的粒度小，併發度高。

表級鎖：

mysql的表級鎖有兩種：元數據鎖和表鎖。

表鎖的兩種形式：

• 表共享讀鎖

• 表排它寫鎖

  • 手動加表鎖

    lock table tableName read;
    複製代碼

  • 查看錶鎖狀況

    show open tables;
    複製代碼

  • 刪除表鎖

    unlock tables;
    複製代碼

元數據鎖：

• 5.5版本中引入了MDL，對一個表數據進行增刪改的時候，加MDL讀鎖；要對錶結構進行修改的時候，加MDL寫鎖。

行級鎖

mysql的行級鎖是有存儲引擎實現的，mysql如今默認的數據引擎爲Innodb。本文主要介紹InnoDB的行鎖；

InnoDB的行鎖是給索引項加鎖實現的，也就意味着只有使用索引檢索的數據才能使用行鎖，不然將使用表鎖。

按照範圍來講

• 行鎖：鎖定表中的某一條記錄。
• 間隙鎖：
  • 鎖住索引記錄中間的值
  • 鎖住第一個索引記錄前面的值或者最後一個索引後面的值

按照功能來講

• 共享鎖，也叫作S鎖：容許一個事務去讀一行數據，阻止其餘事務添加排它鎖，容許繼續添加共享鎖讀
• 排它鎖，也叫作X鎖：容許得到排它鎖的事務更新數據，阻止其餘事務添加讀共享鎖和添加排它鎖寫

對於InnoDB來講，會自動給增刪改語句添加排它鎖，X鎖。對於普通的查詢語句不會添加任何鎖。

意向鎖

InnoDB一樣也實現了表級鎖，也就是意向鎖。意向鎖是mysql內部使用的，不須要用戶去幹預。

• 意向共享鎖，IS鎖：事務打算給數據行加共享鎖，事務在給一個數據行添加共享鎖前必須獲取該表的IS鎖。
• 意向排它鎖，IX鎖：事務打算給數據航加排它鎖，事務在給一個數據行添加排它鎖前必須獲取該表的IX鎖。

意向和行鎖能夠共存，意向鎖的做用是爲了提高全表更新數據時的性能提高，不然在更新全表時要檢索哪些數據行上有行鎖。

間隙鎖

顧名思義，主要是在記錄之間添加鎖，不容許往間隙插入數據。好比id爲 2 4，那此時使用間隙鎖就會鎖2 3 4 這三個，稍後在介紹事務的時候也會再次介紹間隙鎖，間隙鎖的主要做用就是爲了解決幻讀問題。此處先了解一下。

死鎖

mysql的死鎖和咱們代碼中死鎖理論是同樣的，不一樣的是，mysql指的是兩個不一樣的鏈接互相等待對方釋放鎖，才能釋放本身持有的資源，因此形成了死鎖。mysql中也有對死鎖的優化。咱們稍後再具體說。

接下來咱們開始介紹事務，上面只是簡單介紹了一下鎖的基本概念，鎖還有一部份內容須要結合事務來理解，因此稍後還有鎖的介紹。

在咱們介紹事務以前，咱們先聊一下InnoDB的架構，事務中的一些部分會涉及到這部分的內容。

InnoDB的磁盤文件

InnoDB的磁盤文件

• 系統表空間

  • 系統表空是一個共享的表空間
  • 系統表空間包含數據字典、doule write buffer、change buffer、undo log的存儲區域，包含用戶在系統表建立的表結構和索引數據

• 用戶表空間

  • 設置參數 innodb_file_per_table ，用戶就能夠爲每一個基於InnoDB引擎的表建立一個獨立的用戶表空間，也就是.ibd文件。
  • 存儲該表的數據、索引等信息。

InnoDB內存結構

• buff pool 緩衝池
  • 數據是存儲於磁盤的，因爲cpu速度和磁盤速度的差異，因此使用緩衝池提升總體性能。
  • 經過innodb_buffer_pool_size能夠設置緩衝池的大小，緩衝池的大小對性能也是有影響的。
  • 緩衝池中緩衝的數據類型：
    • 索引頁
    • 數據頁
    • 存儲引擎工做時，須要以頁爲單位將磁盤數據加載到內存中，數據頁和索引頁是頁類型中最重要的兩種類型
    • undo頁:實現了mysql多版本的快照，能夠理解爲版本鏈。mvcc和回滾操做都涉及到了undo日誌。
    • insert buffer：提升了對於非聚簇索引的插入性能
    • 自適應哈希索引
    • InnoDB存儲的鎖信息
    • 數據字典信息

內存數據落盤

InnoDB數據落盤有圖能夠看出來是經過兩種方式來實現的

• 髒頁數據落盤
• 預寫redo日誌

經過兩種方式來落盤，也能夠理解爲持久化到磁盤上。是爲了保證數庫發生忽然宕機，形成數據丟失。

髒頁落盤會產生IO而且是隨機寫入，耗時比較長。頻繁進行磁盤IO對性能損耗是很是大。而且數據的安全性得不到保障。若是在髒頁數據還沒來得及落盤或者落盤過程出現宕機，那麼數據就會丟失。

鑑於以上狀況，mysql用雙保險完成數據的安全性，髒頁落盤是一種，另外一種就是預寫redo 日誌，首先咱們要知道redo 持久化到磁盤是順序寫入，順序寫入的速度要比隨機寫入要快，此時有朋友就會問，那髒頁落盤爲何不採用順序寫入呢但？

順序寫入速度快的同時是會產生磁盤碎片的，磁盤碎片會大大浪費磁盤資源。

redo 日誌持久化的時機是在事務提交時寫入到磁盤的redo file中，此時髒頁數據並不必定完成了落盤，髒頁落盤是由checkPoint檢查點機制控制的，咱們這裏不展開多說。

數據庫發生宕機的狀況：

• 髒頁數據未落盤，事務未提交，此時產生了數據丟失，咱們都知道若是事務未提交換個角度來說這些數據丟失是正常的。
• 髒頁數據未落盤，事務已提交，此時redo log file已經有了數據，那麼重啓的時候mysql就會從redo log file中進行數據恢復。

有的朋友還會說，那redo log file的數據豈不是無限大？

ib_logfile0，ib_logfile1 這是rodo log 在咱們磁盤上的命名，能夠看到有兩個文件，採用的循環寫入的方式，若是1滿了就寫入2,2滿了寫入1，這樣循環。

redo 日誌持久化到磁盤也是能夠配置的，經過InnoDB的innodb_push_log_at_trx_commit來設置

1. 屬性值爲0時，事務提交，不會對redo進行寫入操做，等待主線程按時寫入；
2. 屬性值爲1時，事務提交，將數據寫入磁盤，確保不會出現數據丟失；
3. 屬性值爲2時，事務提交，將數據寫入系統緩存，讓文件系統本身判斷何時寫入磁盤。

默認值爲1，通常也建議設置爲1，會保證數據的安全性，而且只有爲1的時候纔會保證事務的一致性。

---

以上就是本篇博文的所有內容，感謝各位看官。歡迎提出問題一塊兒交流探討。

下一篇：mysql的事務和mvcc