?

InnoDB支持行級鎖和表級鎖（默認行級鎖），支持事務，外部鍵等；大量的insert和update更快等。只有通過索引條件檢索數(shù)據(jù)，InnoDB 才使用行級鎖，否則，InnoDB 將使用表鎖。

MyISAM是表級鎖，不支持事務，大量的SELECT查詢更快等

BDB引擎支持頁級鎖和表級鎖（默認頁級鎖）

?

行級鎖

行級鎖是 MySQL 中鎖定粒度最細的一種鎖，表示只針對當前操作的行進行加鎖。行級鎖能大大減少數(shù)據(jù)庫操作的沖突，其加鎖粒度最小，但加鎖的開銷也最大。行級鎖分為共享鎖和排他鎖。

特點

開銷大，加鎖慢；會出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低，并發(fā)度也最高。

表級鎖

表級鎖是 MySQL 中鎖定粒度最大的一種鎖，表示對當前操作的整張表加鎖，它實現(xiàn)簡單，資源消耗較少，被大部分 MySQL 引擎支持。最常使用的 MyISAM 與 InnoDB 都支持表級鎖定。表級鎖定分為表共享讀鎖（共享鎖）與表獨占寫鎖（排他鎖）。

特點

開銷小，加鎖快；不會出現(xiàn)死鎖；鎖定粒度大，發(fā)出鎖沖突的概率最高，并發(fā)度最低。

頁級鎖

頁級鎖是 MySQL 中鎖定粒度介于行級鎖和表級鎖中間的一種鎖。表級鎖速度快，但沖突多，行級沖突少，但速度慢。因此，采取了折衷的頁級鎖，一次鎖定相鄰的一組記錄。BDB 支持頁級鎖。

特點

開銷和加鎖時間界于表鎖和行鎖之間；會出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般。

?

InnoDB 中的行鎖與表鎖

前面提到過，在 InnoDB 引擎中既支持行鎖也支持表鎖，那么什么時候會鎖住整張表？什么時候只鎖住一行呢？

InnoDB 行鎖是通過給索引上的索引項加鎖來實現(xiàn)的，這一點 MySQL 與 Oracle 不同，后者是通過在數(shù)據(jù)塊中對相應數(shù)據(jù)行加鎖來實現(xiàn)的。InnoDB 這種行鎖實現(xiàn)的特點意味著：只有通過索引條件檢索數(shù)據(jù)，InnoDB 才使用行級鎖，否則，InnoDB 將使用表鎖。

在實際應用中，要特別注意 InnoDB 行鎖的這一特性，不然的話，可能導致大量的鎖沖突，從而影響并發(fā)性能。

• 在不通過索引條件查詢的時候，InnoDB 確實使用的是表鎖，而不是行鎖。
• 由于 MySQL 的行鎖是針對索引加的鎖，不是針對記錄加的鎖，因此雖然是訪問不同行的記錄，但是如果是使用相同的索引鍵，是會出現(xiàn)鎖沖突的。應用設(shè)計的時候要注意這一點。
• 當表有多個索引的時候，不同的事務可以使用不同的索引鎖定不同的行，另外，不論是使用主鍵索引、唯一索引還是普通索引，InnoDB 都會使用行鎖來對數(shù)據(jù)加鎖。
• 即便在條件中使用了索引字段，但是否使用索引來檢索數(shù)據(jù)是由 MySQL 通過判斷不同的執(zhí)行計劃的代價來決定的。如果 MySQL 認為全表掃描效率更高，比如對一些很小的表，它就不會使用索引，這種情況下 InnoDB 將使用表鎖，而不是行鎖。因此，在分析鎖沖突時，別忘了檢查 SQL 的執(zhí)行計劃，以確認是否真正使用了索引。

行級鎖與死鎖

MyISAM 中是不會產(chǎn)生死鎖的，因為 MyISAM 總是一次性獲得所需的全部鎖，要么全部滿足，要么全部等待。而在 InnoDB 中，鎖是逐步獲得的，就造成了死鎖的可能。

在 MySQL 中，行級鎖并不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種，如果一條 SQL 語句操作了主鍵索引，MySQL 就會鎖定這條主鍵索引；如果一條 SQL 語句操作了非主鍵索引，MySQL 就會先鎖定該非主鍵索引，再鎖定相關(guān)的主鍵索引。 在進行UPDATE、DELETE操作時，MySQL 不僅鎖定WHERE條件掃描過的所有索引記錄，而且會鎖定相鄰的鍵值，即所謂的next-key locking.

當兩個事務同時執(zhí)行，一個鎖住了主鍵索引，在等待其他相關(guān)索引；另一個鎖定了非主鍵索引，在等待主鍵索引。這樣就會發(fā)生死鎖。

發(fā)生死鎖后，InnoDB 一般都可以檢測到，并使一個事務釋放鎖回退，另一個獲取鎖完成事務。

避免死鎖的方法

有多種方法可以避免死鎖，這里只介紹常見的三種：

如果不同程序會并發(fā)存取多個表，盡量約定以相同的順序訪問表，可以大大降低發(fā)生死鎖的可能性；

在同一個事務中，盡可能做到一次鎖定所需要的所有資源，減少死鎖產(chǎn)生概率；

對于非常容易產(chǎn)生死鎖的業(yè)務部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產(chǎn)生的概率。

死鎖的解決方案：

1、先查看當前庫的線程情況：show? full processlist; 目的看先有沒有這在執(zhí)行的慢sql線程，如果有就kill掉

2、如果沒有，再去查看innodb的事務表INNODB_TRX，看下里面是否有正在鎖定的事務線程，看看ID是否在show full processlist里面的sleep線程中，如果是，就證明這個sleep的線程事務一直沒有commit或者rollback而是卡住了

　　SELECT * FROM information_schema.INNODB_TRX G;如果有就kill掉

?

共享鎖和排他鎖：

1、共享鎖：稱為讀鎖，簡稱S鎖，顧名思義，共享鎖就是多個事務對于同一數(shù)據(jù)可以共享一把鎖，都能訪問到數(shù)據(jù)，但是只能讀不能修改。

2、排他鎖：又稱為寫鎖，簡稱X鎖，顧名思義，排他鎖就是不能與其他所并存，如一個事務獲取了一個數(shù)據(jù)行的排他鎖，其他事務就不能再獲取該行的其他鎖，包括共享鎖和排他鎖，但是獲取排他鎖的事務是可以對數(shù)據(jù)就行讀取和修改。

對于共享鎖大家可能很好理解，就是多個事務只能讀數(shù)據(jù)不能改數(shù)據(jù)，對于排他鎖大家的理解可能就有些差別，我當初就犯了一個錯誤，以為排他鎖鎖住一行數(shù)據(jù)后，其他事務就不能讀取和修改該行數(shù)據(jù)，其實不是這樣的。排他鎖指的是一個事務在一行數(shù)據(jù)加上排他鎖后，其他事務不能再在其上加其他的鎖。mysql InnoDB引擎默認的修改數(shù)據(jù)語句，update,delete,insert都會自動給涉及到的數(shù)據(jù)加上排他鎖，select語句默認不會加任何鎖類型，如果加排他鎖可以使用select ...for update語句，加共享鎖可以使用select ... lock in share mode語句。所以加過排他鎖的數(shù)據(jù)行在其他事務種是不能修改數(shù)據(jù)的，也不能通過for update和lock in share mode鎖的方式查詢數(shù)據(jù)，但可以直接通過select ...from...查詢數(shù)據(jù)，因為普通查詢沒有任何鎖機制。

?

注意：mysql的update、delete、insert是默認加了排他鎖的，而普通的selete是什么鎖都沒加，所以普通selete既能查共享鎖的行也能查排他鎖的行

?

轉(zhuǎn)載于:https://www.cnblogs.com/wzk-0000/p/9928616.html

總結(jié)

以上是生活随笔為你收集整理的mysql数据库引擎InnoDB和MyISAM的区别的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。