mysql 的存儲引擎介紹
在數據庫中存的就是一張張有着千絲萬縷關係的表，所以表設計的好壞，將直接影響着整個數據庫。而在設計表的時候，我們都會關注一個問題，使用什麼存儲引擎。等一下，存儲引擎？什麼是存儲引擎？
什麼是存儲引擎？
MySQL中的數據用各種不同的技術存儲在文件(或者內存)中。這些技術中的每一種技術都使用不同的存儲機制、索引技巧、鎖定水平並且最終提供廣泛的不同的功能和能力。通過選擇不同的技術，你能夠獲得額外的速度或者功能，從而改善你的應用的整體功能。 例如，如果你在研究大量的臨時數據，你也許需要使用內存MySQL存儲引擎。內存存儲引擎能夠在內存中存儲所有的表格數據。又或者，你也許需要一個支持事務處理的數據庫(以確保事務處理不成功時數據的回退能力)。
這些不同的技術以及配套的相關功能在 MySQL中被稱作存儲引擎(也稱作表類型)。 MySQL默認配置了許多不同的存儲引擎，可以預先設置或者在MySQL服務器中啓用。你可以選擇適用於服務器、數據庫和表格的存儲引擎，以便在選擇如何存儲你的信息、如何檢索這些信息以及你需要你的數據結合什麼性能和功能的時候爲你提供最大的靈活性。
關係數據庫表是用於存儲和組織信息的數據結構，可以將表理解爲由行和列組成的表格，類似於Excel的電子表格的形式。有的表簡單，有的表複雜，有的表根本不用來存儲任何長期的數據，有的表讀取時非常快，但是插入數據時去很差；而我們在實際開發過程中，就可能需要各種各樣的表，不同的表，就意味着存儲不同類型的數據，數據的處理上也會存在着差異，那麼。對於MySQL來說，它提供了很多種類型的存儲引擎（或者說不通的表類型），我們可以根據對數據處理的需求，選擇不同的存儲引擎，從而最大限度的利用MySQL強大的功能。
在mysql客戶端中，使用以下命令可以查看MySQL支持的引擎。
show engines;
MyISAM
它不支持事務，也不支持外鍵，尤其是訪問速度快，對事務完整性沒有要求或者以SELECT、INSERT爲主的應用基本都可以使用這個引擎來創建表。
每個MyISAM在磁盤上存儲成3個文件，其中文件名和表名都相同，但是擴展名分別爲：
- .frm(存儲表定義)
- MYD(MYData，存儲數據)
- MYI(MYIndex，存儲索引)
數據文件和索引文件可以放置在不同的目錄，平均分配IO，獲取更快的速度。要指定數據文件和索引文件的路徑，需要在創建表的時候通過DATA DIRECTORY和INDEX DIRECTORY語句指定，文件路徑需要使用絕對路徑。
每個MyISAM表都有一個標誌，服務器或myisamchk程序在檢查MyISAM數據表時會對這個標誌進行設置。MyISAM表還有一個標誌用來表明該數據表在上次使用後是不是被正常的關閉了。如果服務器以爲當機或崩潰，這個標誌可以用來判斷數據表是否需要檢查和修復。如果想讓這種檢查自動進行，可以在啓動服務器時使用--myisam-recover現象。這會讓服務器在每次打開一個MyISAM數據表是自動檢查數據表的標誌並進行必要的修復處理。MyISAM類型的表可能會損壞，可以使用CHECK TABLE語句來檢查MyISAM表的健康，並用REPAIR TABLE語句修復一個損壞到MyISAM表。
MyISAM的表還支持3種不同的存儲格式：
- 靜態(固定長度)表
- 動態表
- 壓縮表
其中靜態表是默認的存儲格式。靜態表中的字段都是非變長字段，這樣每個記錄都是固定長度的，這種存儲方式的優點是存儲非常迅速，容易緩存，出現故障容易恢復；缺點是佔用的空間通常比動態表多。靜態表在數據存儲時會根據列定義的寬度定義補足空格，但是在訪問的時候並不會得到這些空格，這些空格在返回給應用之前已經去掉。同時需要注意：在某些情況下可能需要返回字段後的空格，而使用這種格式時後面到空格會被自動處理掉。
動態表包含變長字段，記錄不是固定長度的，這樣存儲的優點是佔用空間較少，但是頻繁到更新刪除記錄會產生碎片，需要定期執行OPTIMIZE TABLE語句或myisamchk -r命令來改善性能，並且出現故障的時候恢復相對比較困難。
壓縮表由myisamchk工具創建，佔據非常小的空間，因爲每條記錄都是被單獨壓縮的，所以只有非常小的訪問開支。
InnoDB
InnoDB是一個健壯的事務型存儲引擎，這種存儲引擎已經被很多互聯網公司使用，爲用戶操作非常大的數據存儲提供了一個強大的解決方案。我的電腦上安裝的MySQL 5.6.13版，InnoDB就是作爲默認的存儲引擎。InnoDB還引入了行級鎖定和外鍵約束，在以下場合下，使用InnoDB是最理想的選擇：
1.更新密集的表。InnoDB存儲引擎特別適合處理多重併發的更新請求。
2.事務。InnoDB存儲引擎是支持事務的標準MySQL存儲引擎。
3.自動災難恢復。與其它存儲引擎不同，InnoDB表能夠自動從災難中恢復。
4.外鍵約束。MySQL支持外鍵的存儲引擎只有InnoDB。
5.支持自動增加列AUTO_INCREMENT屬性。
一般來說，如果需要事務支持，並且有較高的併發讀取頻率，InnoDB是不錯的選擇。
MEMORY
使用MySQL Memory存儲引擎的出發點是速度。爲得到最快的響應時間，採用的邏輯存儲介質是系統內存。雖然在內存中存儲表數據確實會提供很高的性能，但當mysqld守護進程崩潰時，所有的Memory數據都會丟失。獲得速度的同時也帶來了一些缺陷。它要求存儲在Memory數據表裏的數據使用的是長度不變的格式，這意味着不能使用BLOB和TEXT這樣的長度可變的數據類型，VARCHAR是一種長度可變的類型，但因爲它在MySQL內部當做長度固定不變的CHAR類型，所以可以使用。
一般在以下幾種情況下使用Memory存儲引擎：
1.目標數據較小，而且被非常頻繁地訪問。在內存中存放數據，所以會造成內存的使用，可以通過參數max_heap_table_size控制Memory表的大小，設置此參數，就可以限制Memory表的最大大小。
2.如果數據是臨時的，而且要求必須立即可用，那麼就可以存放在內存表中。
3.存儲在Memory表中的數據如果突然丟失，不會對應用服務產生實質的負面影響。
Memory同時支持散列索引和B樹索引。B樹索引的優於散列索引的是，可以使用部分查詢和通配查詢，也可以使用<、>和>=等操作符方便數據挖掘。散列索引進行“相等比較”非常快，但是對“範圍比較”的速度就慢多了，因此散列索引值適合使用在=和<>的操作符中，不適合在<或>操作符中，也同樣不適合用在order by子句中。
可以在表創建時利用USING子句指定要使用的版本。例如：
複製代碼代碼如下:
create table users
(
id smallint unsigned not null auto_increment,
username varchar(15) not null,
pwd varchar(15) not null,
index using hash (username),
primary key (id)
)engine=memory;
上述代碼創建了一個表，在username字段上使用了HASH散列索引。下面的代碼就創建一個表，使用BTREE索引。
複製代碼代碼如下:
create table users
(
id smallint unsigned not null auto_increment,
username varchar(15) not null,
pwd varchar(15) not null,
index using btree (username),
primary key (id)
)engine=memory;
MERGE
MERGE存儲引擎是一組MyISAM表的組合，這些MyISAM表結構必須完全相同，儘管其使用不如其它引擎突出，但是在某些情況下非常有用。說白了，Merge表就是幾個相同MyISAM表的聚合器；Merge表中並沒有數據，對Merge類型的表可以進行查詢、更新、刪除操作，這些操作實際上是對內部的MyISAM表進行操作。Merge存儲引擎的使用場景。
對於服務器日誌這種信息，一般常用的存儲策略是將數據分成很多表，每個名稱與特定的時間端相關。例如：可以用12個相同的表來存儲服務器日誌數據，每個表用對應各個月份的名字來命名。當有必要基於所有12個日誌表的數據來生成報表，這意味着需要編寫並更新多表查詢，以反映這些表中的信息。與其編寫這些可能出現錯誤的查詢，不如將這些表合併起來使用一條查詢，之後再刪除Merge表，而不影響原來的數據，刪除Merge表只是刪除Merge表的定義，對內部的表沒有任何影響。
ARCHIVE
Archive是歸檔的意思，在歸檔之後很多的高級功能就不再支持了，僅僅支持最基本的插入和查詢兩種功能。在MySQL 5.5版以前，Archive是不支持索引，但是在MySQL 5.5以後的版本中就開始支持索引了。Archive擁有很好的壓縮機制，它使用zlib壓縮庫，在記錄被請求時會實時壓縮，所以它經常被用來當做倉庫使用。
存儲引擎的一些問題
1.如何查看服務器有哪些存儲引擎可以使用？
爲確定你的MySQL服務器可以用哪些存儲引擎，執行如下命令：
複製代碼代碼如下:
show engines;
這個命令就能搞定了。
2.如何選擇合適的存儲引擎？
（1）選擇標準可以分爲：
（2）是否需要支持事務；
（3）是否需要使用熱備；
（4）崩潰恢復：能否接受崩潰；
（5）是否需要外鍵支持；
然後按照標準，選擇對應的存儲引擎即可。
總結
這篇文章總結了幾種比較常用的存儲引擎，對於實際的工作，需要根據具體的情況而定，結合實際的項目實例進行應用，纔是最好的學習方法。
轉自：https://www.cnblogs.com/andy6/p/5789248.html