mysql行級鎖和表級鎖的區(qū)別？1. 程序中非數(shù)據(jù)庫交互操作導(dǎo)致事務(wù)掛起將接口調(diào)用或者文件操作等這一類非數(shù)據(jù)庫交互操作嵌入在 SQL 事務(wù)代碼之中，那么整個事務(wù)很有可能因此掛起（接口不通等待超時或是上

mysql行級鎖和表級鎖的區(qū)別？

1. 程序中非數(shù)據(jù)庫交互操作導(dǎo)致事務(wù)掛起

將接口調(diào)用或者文件操作等這一類非數(shù)據(jù)庫交互操作嵌入在 SQL 事務(wù)代碼之中，那么整個事務(wù)很有可能因此掛起（接口不通等待超時或是上傳下載大附件）。

2. 事務(wù)中包含性能較差的查詢 SQL

事務(wù)中存在慢查詢，導(dǎo)致同一個事務(wù)中的其他 DML 無法及時釋放占用的行鎖，引起行鎖等待。

3. 單個事務(wù)中包含大量 SQL

通常是由于在事務(wù)代碼中加入 for 循環(huán)導(dǎo)致，雖然單個 SQL 運(yùn)行很快，但是 SQL 數(shù)量一大，事務(wù)就會很慢。

4. 級聯(lián)更新 SQL 執(zhí)行時間較久

這類 SQL 容易讓人產(chǎn)生錯覺，例如：update A set ... where ...in (select B) 這類級聯(lián)更新，不僅會占用 A 表上的行鎖，也會占用 B 表上的行鎖，當(dāng) SQL 執(zhí)行較久時，很容易引起 B 表上的行鎖等待。

5. 磁盤問題導(dǎo)致的事務(wù)掛起

極少出現(xiàn)的情形，比如存儲突然離線，SQL 執(zhí)行會卡在內(nèi)核調(diào)用磁盤的步驟上，一直等待，事務(wù)無法提交。

綜上可以看出，如果事務(wù)長時間未提交，且事務(wù)中包含了 DML 操作，那么就有可能產(chǎn)生行鎖等待，引起報錯。

mysql怎么查看是表鎖還是行鎖？

MyISAM不支持事物，所以這些隔離級別是沒有意義的。然后再說一下這些隔離級別和鎖之間的關(guān)系(如在InnoDB中，支持行級鎖)：首先一個事物由begin開始，由commit(成功執(zhí)行)或rollback(執(zhí)行失敗，需要回滾)終止，所以考慮事物問題的時候要考慮到事物的整個生命周期，對同一行數(shù)據(jù)的加鎖解鎖操作是有可能多次執(zhí)行的，因此傳統(tǒng)的2 Phase Locking(2PL，兩階段鎖)才會有很多變種，最簡單的是只要先統(tǒng)一上鎖，后統(tǒng)一釋放鎖就可以了，不用考慮釋放鎖的時間，最嚴(yán)格的是所有的鎖一旦加上之后，必須要等到事物commit或rollback后才可以釋放。舉個例子，有一行數(shù)據(jù) a，有兩個事物T1，T21.read uncommittedT1對a進(jìn)行寫操作，寫之前加了寫鎖，寫之后但是commit前釋放了寫鎖，這時候T2是可以讀a的，由于T1還沒有commit，所以T2就發(fā)生了read uncommitted的情況。2.read committed還是1中的情況，如果T1把a(bǔ)的寫鎖一直保持到T1 commit成功之后再釋放，那么T2在T1 commit之前都是不可以讀a的，就可以避免read uncommitted，這就是read committed。但是這種隔離級別下，如果t1插入了一個以前不存在的新行b，t2是可以讀的，就造成了幻讀的情況。3.repeatable read為了避免幻讀，可以加謂詞鎖延遲新行的添加，比如T2要讀大于5的行，那么就加個謂詞鎖，使得大于5的行不能被添加進(jìn)去，這種實(shí)現(xiàn)基本上也是實(shí)現(xiàn)了serializable read基于鎖的事物只是一種方法，一般被成為悲觀并發(fā)控制。此外，還有：樂觀并發(fā)控制：執(zhí)行讀寫的時候不加鎖，commit的時候檢測是否有沖突，若沒有沖突commit成功，否則需要rollback，值得注意的是，雖然讀寫的時候沒有加鎖，但是檢測的時候是要加鎖的，否則2個沖突的事物可能同時檢測成功，這一點(diǎn)絕大多數(shù)材料里都沒有指出。MVCC：給每個數(shù)據(jù)一個版本號，讀的時候完全不需要鎖，寫的時候看具體實(shí)現(xiàn)，可以選擇樂觀并發(fā)控制，也可以選擇悲觀并發(fā)控制，這種實(shí)現(xiàn)很容易實(shí)現(xiàn)snapshot isolation（也是一種隔離級別，只不過沒有以上幾個名氣大，可以保證每個事物可以看到一個在它發(fā)生之前的數(shù)據(jù)庫完整實(shí)例）。

剖析MySQL InnoDB引擎的行鎖表鎖，怎樣利用鎖解決事務(wù)并發(fā)問題？

多個網(wǎng)絡(luò)用戶同時讀取同一數(shù)據(jù)庫表，并不會產(chǎn)生沖突，只有一部分讀另一部分寫或者大家都要寫數(shù)據(jù)庫時才會產(chǎn)生沖突，數(shù)據(jù)庫執(zhí)行的是并發(fā)操作，也就是說微觀上是串行操作，宏觀上是并行操作。mysql是網(wǎng)絡(luò)數(shù)據(jù)庫，支持多事務(wù)處理，為了保證數(shù)據(jù)庫的一致性，就要在訪問數(shù)據(jù)庫時合理運(yùn)用互斥機(jī)制。

了解這個機(jī)制就好辦了，常用的鎖有共享鎖，也就是讀鎖，排斥鎖也就是寫鎖，還有更新鎖，也就是更新操作時加的鎖，也可以歸類于寫鎖。如果已經(jīng)加了讀鎖了，就不要再加寫鎖了，防止數(shù)據(jù)不一致。如果有寫鎖了就不要再加寫鎖了，防止數(shù)據(jù)庫死鎖。