資深工程師必備技能-—數據庫篇—上篇

資深工程師必備技能-<數據庫篇>

數據庫系統原理

事務

概念
事務指的是滿足 ACID 特性的一組操作,可以通過 Commit 提交一個事務,也可以使用 Rollback 進行回滾。
ACID

  1. 原子性(Atomicity)
    事務被視爲不可分割的最小單元,事務的所有操作要麼全部提交成功,要麼全部失敗回滾。
    回滾可以用回滾日誌來實現,回滾日誌記錄着事務所執行的修改操作,在回滾時反向執行這些修改操作即可。
  2. 一致性(Consistency)
    數據庫在事務執行前後都保持一致性狀態。在一致性狀態下,所有事務對一個數據的讀取結果都是相同的。
  3. 隔離性(Isolation)
    一個事務所做的修改在最終提交以前,對其它事務是不可見的。
  4. 持久性(Durability)
    一旦事務提交,則其所做的修改將會永遠保存到數據庫中。即使系統發生崩潰,事務執行的結果也不能丟失。
    使用重做日誌來保證持久性。
    事務的 ACID 特性概念簡單,但不是很好理解,主要是因爲這幾個特性不是一種平級關係:
    只有滿足一致性,事務的執行結果纔是正確的。
    在無併發的情況下,事務串行執行,隔離性一定能夠滿足。此時只要能滿足原子性,就一定能滿足一致性。
    在併發的情況下,多個事務並行執行,事務不僅要滿足原子性,還需要滿足隔離性,才能滿足一致性。
    事務滿足持久化是爲了能應對數據庫崩潰的情況。
    AUTOCOMMIT
    MySQL 默認採用自動提交模式。也就是說,如果不顯式使用 START TRANSACTION 語句來開始一個事務,那麼每個
    查詢都會被當做一個事務自動提交。

併發一致性

在併發環境下,事務的隔離性很難保證,因此會出現很多併發一致性問題。
丟失修改
T1 和 T2 兩個事務都對一個數據進行修改,T1 先修改,T2 隨後修改,T2 的修改覆蓋了 T1 的修改。
讀髒數據
T1 修改一個數據,T2 隨後讀取這個數據。如果 T1 撤銷了這次修改,那麼 T2 讀取的數據是髒數據。
不可重複讀
T2 讀取一個數據,T1 對該數據做了修改。如果 T2 再次讀取這個數據,此時讀取的結果和第一次讀取的結果不同。
幻影讀
T1 讀取某個範圍的數據,T2 在這個範圍內插入新的數據,T1 再次讀取這個範圍的數據,此時讀取的結果和和第一次
讀取的結果不同。
產生併發不一致性問題主要原因是破壞了事務的隔離性,解決方法是通過併發控制來保證隔離性。併發控制可以通過
封鎖來實現,但是封鎖操作需要用戶自己控制,相當複雜。數據庫管理系統提供了事務的隔離級別,讓用戶以一種更
輕鬆的方式處理併發一致性問題

封鎖粒度
MySQL 中提供了兩種封鎖粒度:行級鎖以及表級鎖。
應該儘量只鎖定需要修改的那部分數據,而不是所有的資源。鎖定的數據量越少,發生鎖爭用的可能就越小,系統的
併發程度就越高。
但是加鎖需要消耗資源,鎖的各種操作(包括獲取鎖、釋放鎖、以及檢查鎖狀態)都會增加系統開銷。因此封鎖粒度
越小,系統開銷就越大。
在選擇封鎖粒度時,需要在鎖開銷和併發程度之間做一個權衡。
封鎖類型

  1. 讀寫鎖
    排它鎖(Exclusive),簡寫爲 X 鎖,又稱寫鎖。
    共享鎖(Shared),簡寫爲 S 鎖,又稱讀鎖。
    有以下兩個規定:
    一個事務對數據對象 A 加了 X 鎖,就可以對 A 進行讀取和更新。加鎖期間其它事務不能對 A 加任何鎖。
    一個事務對數據對象 A 加了 S 鎖,可以對 A 進行讀取操作,但是不能進行更新操作。加鎖期間其它事務能對 A
    加 S 鎖,但是不能加 X 鎖。
  2. 意向鎖
    使用意向鎖(Intention Locks)可以更容易地支持多粒度封鎖。
    在存在行級鎖和表級鎖的情況下,事務 T 想要對錶 A 加 X 鎖,就需要先檢測是否有其它事務對錶 A 或者表 A 中的任
    意一行加了鎖,那麼就需要對錶 A 的每一行都檢測一次,這是非常耗時的。
    意向鎖在原來的 X/S 鎖之上引入了 IX/IS,IX/IS 都是表鎖,用來表示一個事務想要在表中的某個數據行上加 X 鎖或 S
    鎖。有以下兩個規定:
    一個事務在獲得某個數據行對象的 S 鎖之前,必須先獲得表的 IS 鎖或者更強的鎖;
    一個事務在獲得某個數據行對象的 X 鎖之前,必須先獲得表的 IX 鎖。
    通過引入意向鎖,事務 T 想要對錶 A 加 X 鎖,只需要先檢測是否有其它事務對錶 A 加了 X/IX/S/IS 鎖,如果加了就表
    示有其它事務正在使用這個表或者表中某一行的鎖,因此事務 T 加 X 鎖失敗。

解釋如下:
任意 IS/IX 鎖之間都是兼容的,因爲它們只是表示想要對錶加鎖,而不是真正加鎖;
S 鎖只與 S 鎖和 IS 鎖兼容,也就是說事務 T 想要對數據行加 S 鎖,其它事務可以已經獲得對錶或者表中的行的
S 鎖。
封鎖協議

  1. 三級封鎖協議
    一級封鎖協議
    事務 T 要修改數據 A 時必須加 X 鎖,直到 T 結束才釋放鎖。
    可以解決丟失修改問題,因爲不能同時有兩個事務對同一個數據進行修改,那麼事務的修改就不會被覆蓋。
    二級封鎖協議
    在一級的基礎上,要求讀取數據 A 時必須加 S 鎖,讀取完馬上釋放 S 鎖。

可以解決讀髒數據問題,因爲如果一個事務在對數據 A 進行修改,根據 1 級封鎖協議,會加 X 鎖,那麼就不能再加 S
鎖了,也就是不會讀入數據。
三級封鎖協議
在二級的基礎上,要求讀取數據 A 時必須加 S 鎖,直到事務結束了才能釋放 S 鎖。
可以解決不可重複讀的問題,因爲讀 A 時,其它事務不能對 A 加 X 鎖,從而避免了在讀的期間數據發生改變。

  1. 兩段鎖協議
    加鎖和解鎖分爲兩個階段進行。
    可串行化調度是指,通過併發控制,使得併發執行的事務結果與某個串行執行的事務結果相同。
    事務遵循兩段鎖協議是保證可串行化調度的充分條件。例如以下操作滿足兩段鎖協議,它是可串行化調度。
    lock-x(A)…lock-s(B)…lock-s©…unlock(A)…unlock©…unlock(B)
    但不是必要條件,例如以下操作不滿足兩段鎖協議,但是它還是可串行化調度。
    lock-x(A)…unlock(A)…lock-s(B)…unlock(B)…lock-s©…unlock©
    MySQL 隱式與顯示鎖定
    MySQL 的 InnoDB 存儲引擎採用兩段鎖協議,會根據隔離級別在需要的時候自動加鎖,並且所有的鎖都是在同一時
    刻被釋放,這被稱爲隱式鎖定。
    InnoDB 也可以使用特定的語句進行顯示鎖定:
    SELECT … LOCK In SHARE MODE; SELECT … FOR UPDATE;
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章