一、引言

在日常開發中，MySQL資料庫應該都沒少使用吧。對MySQL資料庫的引擎應該也有所瞭解，下面就詳細的學習一下MySQL資料庫的Innodb和MyIASM兩種引擎及各自的憂缺點、鎖機制，也來鞏固一下自己對這塊知識的掌握。

1、檢視MySQL支援的儲存引擎

show engines;

說明：
Support列， YES表示當前版本支援這個儲存引擎， DEFAULT表示該引擎是預設的引擎。NO表示不支援該儲存引擎。可以看出，InnoDB是預設的儲存引擎。在5.1版之前，MyISAM是MySQL的預設資料庫引擎。

2、檢視當前資料庫的儲存引擎

show variables like '%storage_engine%';
 

3、查看錶的儲存引擎

show create table emp \G;

二、儲存引擎

上面介紹瞭如何檢視資料庫和表的引擎命令，下面來看看如何修改預設的儲存引擎。

1、儲存引擎的基本設定

（1）、如何修改MySQL的預設儲存引擎？

修改my.ini或my.cnf配置檔案，在配置檔案裡面[mysqld]節點下增加或修改引數 default-storage-engine，然後重啟資料庫服務。

然後檢查預設儲存引擎，就會看到MyISAM為預設儲存引擎

（2）、如何修改表的儲存引擎？

alter table emp engine = MyISAM;
 

（3）、建立表的時候如何指定儲存引擎？

create table person (id INT) engine=InnoDB;		//只為測試

2、兩種常用的儲存引擎

在MySQL資料庫中，常用的引擎主要是：Innodb和MyIASM。

（1）、Innodb引擎

Innodb引擎提供了對資料庫ACID事務的支援，並且還提供了行級鎖和外來鍵的約束，它的設計目標就是處理大資料容量的資料庫系統。MySQL執行的時候，Innodb會在記憶體中建立緩衝池，用於緩衝資料和索引。但是，該引擎是不支援全文搜尋的。同時，啟動也比較的慢，它是不會儲存表的行數的。當進行select count(*) from table指令的時候，需要進行掃描全表。所以當需要使用資料庫的事務時，該引擎就是首選。由於鎖的粒度小（行鎖），寫操作是不會鎖定全表的，只鎖定某一行

，所以在併發度較高的場景下使用會提升效率的。

（2）、MyIASM引擎

MyIASM在5.1版本之前是MySQL預設引擎，但它不提供事務的支援，也不支援行級鎖和外來鍵。因此當執行insert插入和update更新語句時，即執行寫操作的時候需要鎖定整張表，所以會導致效率會降低。不過和Innodb不同的是，MyIASM引擎是儲存了表的行數，當進行select count(*) from table語句時，可以直接的讀取已經儲存的值而不需要進行掃描全表。所以，如果表的讀操作遠遠多於寫操作時，並且不需要事務的支援的。可以將MyIASM作為資料庫引擎的首選。

（3）、兩種引擎在索引上使用的資料結構

InnoDB和MyISAM兩種引擎所使用的索引的資料結構都是B+樹。

對於MyIASM引擎來說，B+樹的資料結構中儲存的內容實際上是實際資料的地址值。也就是說它的索引和實際資料是分開的，只不過使用索引指向了實際資料。這種索引的模式被稱為非聚集索引。

而Innodb引擎的索引的資料結構也是B+樹，只不過資料結構中儲存的都是實際的資料，這種索引有被稱為聚集索引。索引在下篇文章詳述。

3、兩種引擎的詳細比較

（1）、事務支援

MyISAM不支援事務，而InnoDB支援。

InnoDB是事務安全型的，InnoDB的AUTOCOMMIT預設是開啟的，即每條SQL語句會預設被封裝成一個事務，自動提交。
這樣會影響速度，所以最好是把多條SQL語句顯示放在begin和commit之間，組成一個事務去提交。

MyISAM是非事務安全型的，預設開啟自動提交，適合合併一同提交，減小資料庫多次提交導致的開銷，大大提高效能。

（2）、儲存結構

MyISAM：每個MyISAM在磁碟上儲存成三個檔案。第一個檔案的名字以表的名字開始，副檔名指出檔案型別。
	.frm檔案儲存表定義。
	資料檔案的副檔名為.MYD (MYData)。
	索引檔案的副檔名是.MYI (MYIndex)。

InnoDB：所有的表都儲存在同一個資料檔案中（也可能是多個檔案，或者是獨立的表空間檔案），
InnoDB表的大小隻受限於作業系統檔案的大小，一般為2GB。

（3）、儲存空間

MyISAM：可被壓縮，儲存空間較小。支援三種不同的儲存格式：靜態表(預設，但是注意資料末尾不能有空格，會被去掉)、動態表、壓縮表。

InnoDB：需要更多的記憶體和儲存，它會在主記憶體中建立其專用的緩衝池用於高速緩衝資料和索引。

（4）、可移植性、備份及恢復

MyISAM：資料是以檔案的形式儲存，所以在跨平臺的資料轉移中會很方便。在備份和恢復時可單獨針對某個表進行操作。

InnoDB：免費的方案可以是拷貝資料檔案、備份 binlog，或者用 mysqldump，在資料量達到幾十G的時候就相對痛苦了。

（5）、事務支援

MyISAM：強調的是效能，每次查詢具有原子性，其執行速度比InnoDB型別更快，但是不提供事務支援。

InnoDB：提供事務支援事務，外部鍵等高階資料庫功能。 具有事務(commit)、回滾(rollback)和崩潰修復能力
(crash recovery capabilities)的事務安全(transaction-safe (ACID compliant))型表。

（6）、AUTO_INCREMENT

MyISAM：可以和其他欄位一起建立聯合索引。引擎的自動增長列必須是索引，如果是組合索引，自動增長可以不是第一列，
它可以根據前面幾列進行排序後遞增。

InnoDB：InnoDB中必須包含只有該欄位的索引。引擎的自動增長列必須是索引，如果是組合索引也必須是組合索引的第一列。

（7）、表鎖差異（☆☆☆☆）

MyISAM：只支援表級鎖，使用者在操作表時，select，update，delete，insert語句都會給表自動加鎖，
如果加鎖以後的表滿足insert併發的情況下，可以在表的尾部插入新的資料。

InnoDB：支援事務和行級鎖，是InnoDB的最大特色。行鎖大幅度提高了多使用者併發操作的新能。
但是InnoDB的行鎖，只是在WHERE的主鍵是有效的，非主鍵的WHERE都會鎖全表的。

注意：MyISAM鎖的粒度是表級，而InnoDB支援行級鎖定。簡單來說就是, InnoDB支援資料行鎖定，而MyISAM不支援行鎖定，只支援鎖定整個表。即MyISAM同一個表上的讀鎖和寫鎖是互斥的，MyISAM併發讀寫時如果等待佇列中既有讀請求又有寫請求，預設寫請求的優先順序高，即使讀請求先到，所以MyISAM不適合於有大量查詢和修改並存的情況，那樣查詢程序會長時間阻塞。因為MyISAM是鎖表，所以某項讀操作比較耗時會使其他寫程序餓死。

（8）、全文索引

MyISAM：支援(FULLTEXT型別的)全文索引

InnoDB：不支援(FULLTEXT型別的)全文索引，但是InnoDB可以使用sphinx外掛支援全文索引，並且效果更好。

（9）、 表主鍵

MyISAM：允許沒有任何索引和主鍵的表存在，索引都是儲存行的地址。

InnoDB：如果沒有設定主鍵或者非空唯一索引，就會自動生成一個6位元組的主鍵(使用者不可見)，資料是主索引的一部分，
附加索引儲存的是主索引的值。InnoDB的主鍵範圍更大，最大是MyISAM的2倍。

（10）、 表的具體行數

MyISAM：儲存有表的總行數，如果select count(*) from table;會直接取出出該值。

InnoDB：沒有儲存表的總行數(只能遍歷)，如果使用select count(*) from table；
就會遍歷整個表，消耗相當大，但是在加了wehre條件後，MyISAM和InnoDB處理的方式都一樣。

（11）、 CURD操作

MyISAM：如果執行大量的SELECT，MyISAM是更好的選擇。

InnoDB：如果執行大量的INSERT或UPDATE，出於效能方面的考慮，應該使用InnoDB表。DELETE 從效能上InnoDB更優，
但DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除，在InnoDB上如果要清空儲存有大量資料的表，
最好使用truncate table這個命令。

（12）、外來鍵

MyISAM：不支援
InnoDB：支援

4、兩種引擎的選擇：

通過上述的分析，基本上可以考慮使用InnoDB來替代MyISAM引擎了，原因是InnoDB自身很多良好的特點，比如事務支援、儲存過程、檢視、行級鎖定等等。在併發很多的情況下，相信InnoDB的表現肯定要比MyISAM強很多。

（1）、當大容量的資料集時，趨向於選擇Innodb。因為它支援事務處理和故障的恢復。Innodb可以利用資料日誌來進行資料的恢復。主鍵的查詢在Innodb也是比較快的。

（2）、大批量的插入語句時（這裡是INSERT語句），在MyIASM引擎中執行的比較的快，但是UPDATE語句在Innodb下執行的會比較的快，尤其是在併發量大的時候。

（3）、MyISAM管理非事務表。它提供高速儲存和檢索，以及全文搜尋能力。如果應用中需要執行大量的SELECT查詢，那麼MyISAM是更好的選擇。

但是實際場景中，具體情況要具體分析，一般而言可以遵循以下幾個問題：

• 資料庫是否有外來鍵？
• 是否需要事務支援？
• 是否需要全文索引？
• 資料庫經常使用什麼樣的查詢模式？在寫多讀少的應用中還是Innodb插入效能更穩定，在併發情況下也能基本，如果是對讀取速度要求比較快的應用還是選MyISAM。
• 資料庫的資料有多大？ 大尺寸傾向於innodb，因為事務日誌，故障恢復。

5、MyISAM和InnoDB對比總結

對比項	MyISAM	InnoDB
主外來鍵	不支援	支援
事務	不支援	支援
行表鎖	表鎖，即使操作一條記錄也會鎖住整個表，不適合高併發的操作	行鎖，操作時只鎖某一行，不對其它行有影響，適合高併發的操作
快取	只快取索引，不快取真實資料	不僅快取索引，還要快取真實資料，對記憶體要求較高，而且記憶體大小對效能有決定性的影響
表空間	小	大
關注點	效能（偏讀）	事務
預設安裝	Yes	Yes

三、MySQL鎖機制

鎖是計算機協調多個程序或執行緒併發訪問某一資源的機制。在資料庫中，除傳統的計算資源（如CPU、RAM、I/O等）的爭用外，資料也是一種供許多用於共享的資源，如何保證資料併發訪問的一致性、有效性是所有資料庫必須解決的一個問題，鎖衝突也是影響資料庫併發訪問效能的一個重要因素。從這個角度來說，鎖對資料庫而已顯得尤其重要，也更加複雜。

1、鎖的分類：

（1）、從對資料操作的型別分為：

讀鎖（共享鎖）：針對同一份資料，多個讀操作可以同時進行而不會互相影響；
寫鎖（排他鎖）：當前寫操作沒有完成前，它會阻斷其他寫鎖和讀鎖；

（2）、從對資料操作的粒度分為：

表鎖（偏讀）：偏向MyISAM儲存引擎，開銷小，加鎖快，鎖定粒度大，發生鎖衝突的概率最高，併發性最低；
行鎖（偏寫）：偏向InnoDB儲存引擎，開銷大，加鎖慢，會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高；

2、鎖的操作：

查看錶上加過的鎖：

show open tables;

手動增加表鎖：

lock table 表1 read, 表2 write, ……;		//給表1加讀鎖，給表2加寫鎖；

釋放表鎖：

unlock tables;

3、間隙鎖：

當我們用範圍條件而不是相等條件檢索資料，並請求共享或排他鎖時，InnoDB會給符合條件的已有記錄的索引項加鎖，對於鍵值在條件範圍內但並不存在的記錄，叫做“間隙”，InnoDB也會對這個“間隙”加鎖，這種鎖機制就是所謂的間隙鎖（Next-Key鎖）。此時在間隙中進行插入操作會被阻塞。

間隙鎖的危害：

（1）、因為Query執行過程中通過範圍查詢的話，它會鎖定整個範圍內所有的索引鍵值，即使這個鍵值並不存在；
（2）、間隙鎖有一個比較致命的弱點，就是當鎖定一個範圍鍵值之後，即使某些不存在的鍵值也會被無辜的鎖定，而造成在鎖定的時候無法插入鎖定鍵值範圍內的任何資料，在某些場景下這可能會對效能造成很大的危害；

4、MyISAM引擎的鎖機制

該引擎在執行查詢語句（select）前，會自動給涉及的所有表加讀鎖，在執行增刪改操作前，會自動給涉及的表加寫鎖；

MySQL的表級鎖有兩種模式：

表共享讀鎖（Table Read Lock）
表獨佔寫鎖（Table Write Lock）

結論：

（1）、對MyISAM表的讀操作（加讀鎖），不會阻塞其他程序對同一表的讀請求，但會阻塞對同一表的請求，只有當讀鎖釋放後，才會執行其他程序的寫操作；

（2）、對MyISAM表的寫操作（加寫鎖），會阻塞其他程序對同一表的讀和寫操作，只有當寫鎖釋放後，才會執行其他程序的讀寫操作；

簡而言之：就是讀鎖會阻塞寫，但是不會阻塞讀。而寫鎖則會把讀和寫都讀鎖。

5、索引失效，行鎖會變表鎖（☆☆☆☆）

（1）、儘可能讓所有資料檢索都通過索引來完成，避免無索引行鎖升級為表鎖；
（2）、合理設計索引，儘量縮小鎖的範圍；
（3）、儘可能較少檢索條件，避免間隙鎖；
（4）、儘量控制事務大小，減少鎖定資源量和時間長度；
（5）、儘可能低級別事務隔離；

四、小結：

（1）、InnoDB與MyISAM的最大不同有兩點：一是支援事務（Transaction），二是採用了行級鎖；

（2）、InnoDB儲存引擎由於實現了行級鎖定，雖然在鎖定機制的實現方面所帶來的效能損耗可能比表級鎖會更高一些，但是在整體併發處理能力方面要遠遠優於MyISAM的表級鎖定的，當系統併發量較高的時候，InnoDB的整體效能和MyISAM相比就會有比較明顯優勢了；

（3）、但是，InnoDB的行級鎖同樣也有其脆弱的一面，當我們使用不當的時候，可能會讓InnoDB的整體效能表現不僅不能比MyISAM高，甚至可能更差；