面試必問的MySQL鎖與事務隔離級別

時間 2019-11-07

原文原文鏈接

以前多篇文章從mysql的底層結構分析、sql語句的分析器以及sql從優化底層分析，還有工做中經常使用的sql優化小知識點。面試各大互聯網公司必問的mysql鎖和事務隔離級別，這篇文章給你打神助攻，一飛沖天。mysql

鎖定義

鎖是計算機協調多個進程或線程併發訪問某一資源的機制。
在數據庫中，除了傳統的計算資源（如 CPU、RAM、I/O等）的爭用之外，數據也是一種須要用戶共享的資源。如何保證數據併發訪問的一致性、有效性是全部數據庫須要解決的問題，鎖衝突也是影響數據庫併發性能的一個重要因素。web

鎖分類

從性能上分爲樂觀鎖和悲觀鎖
從數據庫操做的類型分爲讀鎖和寫鎖

讀鎖：針對同一份數據，多個讀操做能夠同時進行而不會互相影響
寫鎖：當前寫操做沒有完成前，它會阻斷其餘寫鎖和讀鎖面試

從對數據的操做粒度分爲表鎖和行鎖sql

表鎖
每次操做會鎖住整張表。
優勢：開銷小，加鎖快，不會出現死鎖
缺點：鎖的粒度大，發生鎖衝突的機率高，併發度最低

--手動增長表鎖
lock table 表名稱 read(write),表名稱2 read(write);
--查看錶上加過的鎖
show open tables;
--刪除表鎖
unlock tables;

加讀鎖

lock table 表名 read;

當前session和其餘session均可以讀該表；
當前session中插入或者更新鎖定的表都會報錯，其餘session插入或更新則會等待。數據庫

加寫鎖

lock table 表名 write;

當前session對該表的增刪改查都沒有問題，其餘session對該表的全部操做被阻塞。編程

MyISAM表分析

MyISAM在執行查詢語句select前，會自動給涉及的全部表加讀鎖，在執行增刪該操做前，會自動給涉及的表加寫鎖。
對MyISAM表的讀操做（加讀鎖），不會阻礙其餘進程對同一表的讀請求，但會阻礙對同一表的寫請求。只有當讀鎖釋放後，纔會執行其餘操做的寫操做。
對MyISAM表的寫操做（加寫鎖），會阻塞其餘進程對同一表的讀和寫操做，只有當寫鎖釋放後，纔會執行其餘進程的讀寫操做。後端

行鎖

每次總鎖住一行數據。
優勢：鎖粒度最小，發生鎖衝突機率最低，併發度最高
缺點：開銷大、加鎖慢，會出現死鎖；session

行鎖支持事務

事務是由一組SQL語句組成的邏輯處理單元，事務具備如下4個屬性，一般簡稱爲事務的ACID屬性。數據結構

原子性（Atomicity）：事務是一個原子操做單元，對數據的修改，要麼所有執行，要麼所有不執行。
一致性（Consistent）：在事務開始和完成時，數據都必須保持一致的狀態。意味着全部相關的數據規則都必須應用於事務的修改，以保持數據的完整性；事務結束時，全部的內部數據結構也都必須是正確的。
隔離性（Isolation）：數據庫系統提供必定的隔離機制，保證事務在不受外部併發操做影響的「獨立」環境執行。這意味着事務處理過程當中的中間狀態對外部是不可見的，反之亦然。
持久性（Durable）：事務完成以後，它對於數據的修改是永久性的，即便出現系統故障也能保持。

併發事務處理帶來的問題

更新丟失（Lost Update）
當兩個或多個事務選擇同一行，而後基於最初選定的值更新改行時，有於每一個事務都不知道其餘事務的存在，就會發生更i性能問題：最後的更新覆蓋了由其餘事務所作的更新。
髒讀（Dirty Reads）
一個事務正在對一條記錄作修改，在這個事務完成並提交前，這條記錄的數據就處於不一致的狀態；這時，另外一個事務也來讀取同一條記錄，若是不加控制，第二個事務讀取了這些「髒」數據，並據此進一步的處理，就會產生未提交的數據依賴關係。這種現象被稱爲「髒讀」。
事務A讀取到事務B已經修改但未提交的數據，還在這個數據基礎上作了修改。此時，若是事務B回滾了，事務A的數據無效，不符合一致性要求。
不可重讀（Non-Repetable Reads）
一個事務在讀取某些數據後的某個時間，再次讀取之前讀過的數據，卻發現起讀出的數據已經發生了改變、或某些記錄已經被刪除。這種現象叫作「不可重讀」。
事務A讀取到了事務B已經提交的修改數據，不符合隔離性。
幻讀（Phantom Reads）
一個事務按照相同的查詢條件讀取之前檢索過的數據，卻發現某些事務插入了知足其查詢條件的新數據，這種現象稱爲「幻讀」。
事務A讀取了事務B提交的新增數據，不符合隔離性。