(一)MyISAM
它不支持事務，也不支持外鍵，尤其是訪問速度快，對事務完整性沒有要求或者以SELECT、INSERT為主的應用基本都可以使用這個引擎來創建表。
每個MyISAM在磁碟上存儲成3個文件，其中文件名和表名都相同，但是擴展名分別為：
.frm(存儲表定義)
MYD(MYData，存儲數據)
MYI(MYIndex，存儲索引)
(二)InnoDB
InnoDB存儲引擎提供了具有提交、回滾和崩潰恢復能力的事務安全。但是對比MyISAM的存儲引擎，InnoDB寫的處理效率差一些並且會佔用更多的磁碟空間以保留數據和索引。
(三)MEMORY
memory使用存在內存中的內容來創建表。每個MEMORY表實際對應一個磁碟文件，格式是.frm。MEMORY類型的表訪問非常快，因為它到數據是放在內存中的，並且默認使用HASH索引，但是一旦伺服器關閉，表中的數據就會丟失，但表還會繼續存在。
默認情況下，memory數據表使用散列索引，利用這種索引進行「相等比較」非常快，但是對「范圍比較」的速度就慢多了。因此，散列索引值適合使用在"="和"<=>"的操作符中，不適合使用在"<"或">"操作符中，也同樣不適合用在orderby字句里。如果確實要使用"<"或">"或betwen操作符，可以使用btree索引來加快速度。
存儲在MEMORY數據表裡的數據行使用的是長度不變的格式，因此加快處理速度，這意味著不能使用BLOB和TEXT這樣的長度可變的數據類型。VARCHAR是一種長度可變的類型，但因為它在MySQL內部當作長度固定不變的CHAR類型，所以可以使用。
四)MERGE
merge存儲引擎是一組MyISAM表的組合，這些MyISAM表結構必須完全相同，MERGE表中並沒有數據，對MERGE類型的表可以進行查詢、更新、刪除的操作，這些操作實際上是對內部的MyISAM表進行操作。對於對MERGE表進行的插入操作，是根據INSERT_METHOD子句定義的插入的表，可以有3個不同的值，first和last值使得插入操作被相應的作用在第一個或最後一個表上，不定義這個子句或者為NO，表示不能對這個MERGE表進行插入操作。可以對MERGE表進行drop操作，這個操作只是刪除MERGE表的定義，對內部的表沒有任何影響。MERGE在磁碟上保留2個以MERGE表名開頭文件：.frm文件存儲表的定義；.MRG文件包含組合表的信息，包括MERGE表由哪些表組成，插入數據時的依據。可以通過修改.MRG文件來修改MERGE表，但是修改後要通過flushtable刷新。
『貳』 mysql常見的三種存儲引擎
存儲引擎
MySQL中的數據用各種不同的技術存儲在文件（或者內存）中。這些技術中的每一種技術都使用不同的存儲機制、索引技巧、鎖定水平並且最終提供廣泛的不同的功能和能力。通過選擇不同的技術，你能夠獲得額外的速度或者功能，從而改善你的應用的整體功能。
中文名
存儲引擎
內存存儲引擎
能夠在內存中存儲所有表格數據
類型
MyISAM InnoDB等
優點
靈活
快速
導航
分類
介紹
例如，如果你在研究大量的臨時數據，你也許需要使用內存存儲引擎。內存存儲引擎能夠在內存中存儲所有的表格數據。又或者，你也許需要一個支持事務處理的資料庫(以確保事務處理不成功時數據的回退能力)。
這些不同的技術以及配套的相關功能在MySQL中被稱作存儲引擎(也稱作表類型)。MySQL默認配置了許多不同的存儲引擎，可以預先設置或者在MySQL伺服器中啟用。你可以選擇適用於伺服器、資料庫和表格的存儲引擎，以便在選擇如何存儲你的信息、如何檢索這些信息以及你需要你的數據結合什麼性能和功能的時候為你提供最大的靈活性。
選擇如何存儲和檢索你的數據的這種靈活性是MySQL為什麼如此受歡迎的主要原因。其它資料庫系統(包括大多數商業選擇)僅支持一種類型的數據存儲。遺憾的是，其它類型的資料庫解決方案採取的「一個尺碼滿足一切需求」的方式意味著你要麼就犧牲一些性能，要麼你就用幾個小時甚至幾天的時間詳細調整你的資料庫。使用MySQL，我們僅需要修改我們使用的存儲引擎就可以了[1]
『叄』 如何高效地利用MySQL索引
1、要想高效利用索引，我們首先要考慮如何正確建立索引。
（1）在經常做搜索的列上，也就是WHERE子句里經常出現的列，考慮加上索引，加快搜索速度。
（2）唯一標識記錄的列，應該加上唯一索引，強制該列的唯一性並且加快按該列查找記錄的速度。
（3）在內連接使用的列上加上索引，最好是在內連接用到欄位都加上，因為MySQL優化器會自動地選擇連接順序，然後觀察索引的使用情況，將沒用的索引刪除即可。
（4）在需要排序的列上加上索引，因為索引本身是按順序的組織的，它可以避免 filesort，要知道，Server層在進行排序時是在內存中進行的，非常消耗資源。
（5）可以考慮實現覆蓋索引，即根據 SELECT 的所有欄位上創建聯合索引，這樣存儲引擎只用讀取索引而不用去回表查詢，極大地減少了對數據表的訪問，大大地提高了性能。
（6）對於那些選擇性很小的列，比如性別列，增加索引並不能明顯加快查詢速度，反而該索引會成為表的累贅。
（7）對於那些定義為text, image和bit數據類型的列不應該增加索引。這是因為，這些列的要麼數據量相當大，要麼取值很少。
（8）當對寫性能的要求遠遠大於讀性能時，不應該創建索引。寫性能和讀性能是互相矛盾的。這是因為，維護一個 B+Tree 成本是非常大的，對索引的寫會涉及到頁的分裂等。
（9）復合索引的幾個欄位是否經常同時以AND方式出現在Where子句中？單欄位查詢是否極少甚至沒有？如果是，則可以建立復合索引，否則考慮單欄位索引。這還是說明，滿足查詢性能的前提下，索引越少越好。
（10）如果復合索引所包含的欄位超過3個，那麼仔細考慮其必要性，考慮減少復合的欄位。
（11）在用於GROUP BY的列上加上索引，避免使用臨時表。
（12）對於較長的字元列，如 char、varchar等，由於字元串的比較相對來說非常耗時，因此考慮使用前綴索引減少索引長度，或者創建自定義哈希索引，將字元串映射成整數，然後以該整數作為索引，同時以字元串的值作為過濾條件。
我們在創建索引時，可以根據下面原則進行簡單判斷：索引是否將相關記錄集合到了一起，從未減少了磁碟I/O，加快搜索速度？索引中數據的排列順序是否和查找的數據的排列順序一致，從而避免了Server層的排序？索引中的列是否包含了查詢中需要的全部列從而實現了覆蓋索引？ 這幾個條件層層遞進，滿足得越多越好。
2、索引正確地建立了，我們還需要正確地使用它們：
（1）使用了運算符 !=，以及關鍵字not in，not exist，>，<等，總之產生的結果集很大時（也在where條件進行大范圍的選擇時），往往導致引擎不使用索引而是走全盤掃描。因為如果使用索引會造成大量的隨機I/O，得不償失。
（2）如果對索引列進行運算，如 WHERE substr(name, 1, 3)=『mark』，存儲引擎並不能聰明地判斷哪些索引滿足等式，因此不能使用到索引。
（3）使用到了LIKE，並且通配符在最前面時，不能使用索引。
（4）對於聯合索引 (a, b, c)，如果沒用到最左列，那麼一般情況下都使用不到索引。但是，比如統計操作 count(*) where a > xxx，是可以使用到該聯合索引的。畢竟統計這類操作，它不是檢索，並不需要索引完全有序。
（5）對於聯合索引，如果某個列使用了范圍查找，那麼其右邊的列都無法作為索引優化查詢，但是由於 ICP（Index Condition Pushdown），這些列能作為過濾條件在存儲引擎中對數據進行過濾。
（6）如果條件中有 OR，則必須每個OR用到的欄位都有索引，否則不能使用任何索引。
（7）想在聯合查詢中使用索引來避免 filesort，則關聯查詢中的ORDER BY用到的欄位必須全部是第一張表（驅動表）上的。
『肆』 mysql innodb存儲引擎，聚集索引和輔助索引，採用什麼數據結構
默認B-TREE
『伍』 哪些存儲引擎支持b樹索引，哪些支持hash索引
對B樹的寫入過程是一次原位寫入的過程，主要分為兩個部分，首先是查找到對應的塊的位置，然後將新數據寫入到剛才查找到的數據塊中，然後再查找到塊所對應的磁碟物理位置，將數據寫入去。當然，在內存比較充足的時候，因為B樹的一部分可以被緩存在內存中，所以查找塊的過程有一定概率可以在內存內完成，不過為了表述清晰，我們就假定內存很小，只夠存一個B樹塊大小的數據吧。可以看到，在上面的模式中，需要兩次隨機尋道（一次查找，一次原位寫），才能夠完成一次數據的寫入，代價還是很高的。
通常也常見於其他存儲引擎的查找速度優化上。 Hash 索引結構的特殊性，其檢索效率非常高，索引的檢索可以一次定位，不像B-Tree 索引需要從根節點到枝節點，最後才能訪問到頁節點這樣多次的IO訪問，所以 Hash 索引的查詢效率要遠高於 B-Tree 索引。雖然 Hash 索引效率高，但是 Hash 索引本身由於其特殊性也帶來了很多限制和弊端，代表資料庫：redis、memcache等
『陸』 如何寫MySQL存儲引擎
MySQL有多種存儲引擎，每種存儲引擎有各自的優缺點，可以擇優選擇使用：
MyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)、EXAMPLE、FEDERATED、ARCHIVE、CSV、BLACKHOLE。
MySQL支持數個存儲引擎作為對不同表的類型的處理器。MySQL存儲引擎包括處理事務安全表的引擎和處理非事務安全表的引擎：
· MyISAM管理非事務表。它提供高速存儲和檢索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，它是默認的存儲引擎，除非你配置MySQL默認使用另外一個引擎。
· MEMORY存儲引擎提供「內存中」表。MERGE存儲引擎允許集合將被處理同樣的MyISAM表作為一個單獨的表。就像MyISAM一樣，MEMORY和MERGE存儲引擎處理非事務表，這兩個引擎也都被默認包含在MySQL中。
注釋：MEMORY存儲引擎正式地被確定為HEAP引擎。
· InnoDB和BDB存儲引擎提供事務安全表。BDB被包含在為支持它的操作系統發布的MySQL-Max二進制分發版里。InnoDB也默認被包括在所 有MySQL 5.1二進制分發版里，你可以按照喜好通過配置MySQL來允許或禁止任一引擎。
· EXAMPLE存儲引擎是一個「存根」引擎，它不做什麼。你可以用這個引擎創建表，但沒有數據被存儲於其中或從其中檢索。這個引擎的目的是服務，在 MySQL源代碼中的一個例子，它演示說明如何開始編寫新存儲引擎。同樣，它的主要興趣是對開發者。
· NDB Cluster是被MySQL Cluster用來實現分割到多台計算機上的表的存儲引擎。它在MySQL-Max 5.1二進制分發版里提供。這個存儲引擎當前只被Linux, Solaris, 和Mac OS X 支持。在未來的MySQL分發版中，我們想要添加其它平台對這個引擎的支持，包括Windows。
· ARCHIVE存儲引擎被用來無索引地，非常小地覆蓋存儲的大量數據。
· CSV存儲引擎把數據以逗號分隔的格式存儲在文本文件中。
· BLACKHOLE存儲引擎接受但不存儲數據，並且檢索總是返回一個空集。
· FEDERATED存儲引擎把數據存在遠程資料庫中。在MySQL 5.1中，它只和MySQL一起工作，使用MySQL C Client API。在未來的分發版中，我們想要讓它使用其它驅動器或客戶端連接方法連接到另外的數據源。
比較常用的是MyISAM和InnoBD
『柒』 mysql存儲引擎類型有哪些
1、MyISAM
使用這個存儲引擎，每個MyISAM在磁碟上存儲成三個文件。
（1）frm文件：存儲表的定義數據
（2）MYD文件：存放表具體記錄的數據
（3）MYI文件：存儲索引
frm和MYI可以存放在不同的目錄下。MYI文件用來存儲索引，但僅保存記錄所在頁的指針，索引的結構是B+樹結構。下面這張圖就是MYI文件保存的機制：
從這張圖可以發現，這個存儲引擎通過MYI的B+樹結構來查找記錄頁，再根據記錄頁查找記錄。並且支持全文索引、B樹索引和數據壓縮。
支持數據的類型也有三種：
（1）靜態固定長度表
這種方式的優點在於存儲速度非常快，容易發生緩存，而且表發生損壞後也容易修復。缺點是占空間。這也是默認的存儲格式。
（2）動態可變長表
優點是節省空間，但是一旦出錯恢復起來比較麻煩。
（3）壓縮表
上面說到支持數據壓縮，說明肯定也支持這個格式。在數據文件發生錯誤時候，可以使用check table工具來檢查，而且還可以使用repair table工具來恢復。
有一個重要的特點那就是不支持事務，但是這也意味著他的存儲速度更快，如果你的讀寫操作允許有錯誤數據的話，只是追求速度，可以選擇這個存儲引擎。
2、InnoDB
InnoDB是默認的資料庫存儲引擎，他的主要特點有：
（1）可以通過自動增長列，方法是auto_increment。
（2）支持事務。默認的事務隔離級別為可重復度，通過MVCC（並發版本控制）來實現的。
（3）使用的鎖粒度為行級鎖，可以支持更高的並發；
（4）支持外鍵約束；外鍵約束其實降低了表的查詢速度，但是增加了表之間的耦合度。
（5）配合一些熱備工具可以支持在線熱備份；
（6）在InnoDB中存在著緩沖管理，通過緩沖池，將索引和數據全部緩存起來，加快查詢的速度；
（7）對於InnoDB類型的表，其數據的物理組織形式是聚簇表。所有的數據按照主鍵來組織。數據和索引放在一塊，都位於B+數的葉子節點上；
當然InnoDB的存儲表和索引也有下面兩種形式：
（1）使用共享表空間存儲：所有的表和索引存放在同一個表空間中。
（2）使用多表空間存儲：表結構放在frm文件，數據和索引放在IBD文件中。分區表的話，每個分區對應單獨的IBD文件，分區表的定義可以查看我的其他文章。使用分區表的好處在於提升查詢效率。
對於InnoDB來說，最大的特點在於支持事務。但是這是以損失效率來換取的。
3、Memory
將數據存在內存，為了提高數據的訪問速度，每一個表實際上和一個磁碟文件關聯。文件是frm。
（1）支持的數據類型有限制，比如：不支持TEXT和BLOB類型，對於字元串類型的數據，只支持固定長度的行，VARCHAR會被自動存儲為CHAR類型；
（2）支持的鎖粒度為表級鎖。所以，在訪問量比較大時，表級鎖會成為MEMORY存儲引擎的瓶頸；
（3）由於數據是存放在內存中，一旦伺服器出現故障，數據都會丟失；
（4）查詢的時候，如果有用到臨時表，而且臨時表中有BLOB，TEXT類型的欄位，那麼這個臨時表就會轉化為MyISAM類型的表，性能會急劇降低；
（5）默認使用hash索引。
（6）如果一個內部表很大，會轉化為磁碟表。
在這里只是給出3個常見的存儲引擎。使用哪一種引擎需要靈活選擇，一個資料庫中多個表可以使用不同引擎以滿足各種性能和實際需求，使用合適的存儲引擎，將會提高整個資料庫的性能
『捌』 如何使用索引提高查詢速度
人們在使用SQL時往往會陷入一個誤區，即太關注於所得的結果是否正確，而忽略了不同的實現方法之間可能存在的
性能差異，這種性能差異在大型的或是復雜的資料庫環境中（如聯機事務處理OLTP或決策支持系統DSS）中表現得尤為明
顯。筆者在工作實踐中發現，不良的SQL往往來自於不恰當的索引設計、不充份的連接條件和不可優化的where子句。在對
它們進行適當的優化後，其運行速度有了明顯地提高！下面我將從這三個方面分別進行總結：
---- 為了更直觀地說明問題，所有實例中的SQL運行時間均經過測試，不超過1秒的均表示為（< 1秒）。
---- 測試環境--
---- 主機：HP LH II
---- 主頻：330MHZ
---- 內存：128兆
---- 操作系統：Operserver5.0.4
----資料庫：Sybase11.0.3
一、不合理的索引設計
----例：表record有620000行，試看在不同的索引下，下面幾個 SQL的運行情況：
---- 1.在date上建有一個非群集索引
select count(*) from record where date >'19991201' and date < '19991214'and amount >2000 (25秒)
select date,sum(amount) from record group by date(55秒)
select count(*) from record where date >'19990901' and place in ('BJ','SH') (27秒)
---- 分析：
----date上有大量的重復值，在非群集索引下，數據在物理上隨機存放在數據頁上，在范圍查找時，必須執行一次表掃描才能找到這一范圍內的全部行。
---- 2.在date上的一個群集索引
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000（14秒）
select date,sum(amount) from record group by date（28秒）
select count(*) from record where date >'19990901' and place in ('BJ','SH')（14秒）
---- 分析：
---- 在群集索引下，數據在物理上按順序在數據頁上，重復值也排列在一起，因而在范圍查找時，可以先找到這個范圍的起末點，且只在這個范圍內掃描數據頁，避免了大范圍掃描，提高了查詢速度。
---- 3.在place，date，amount上的組合索引
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000（26秒）
select date,sum(amount) from record group by date（27秒）
select count(*) from record where date >'19990901' and place in ('BJ, 'SH')（< 1秒）
---- 分析：
---- 這是一個不很合理的組合索引，因為它的前導列是place，第一和第二條SQL沒有引用place，因此也沒有利用上索引；第三個SQL使用了place，且引用的所有列都包含在組合索引中，形成了索引覆蓋，所以它的速度是非常快的。
---- 4.在date，place，amount上的組合索引
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000(< 1秒)
select date,sum(amount) from record group by date（11秒）
select count(*) from record where date >'19990901' and place in ('BJ','SH')（< 1秒）
---- 分析：
---- 這是一個合理的組合索引。它將date作為前導列，使每個SQL都可以利用索引，並且在第一和第三個SQL中形成了索引覆蓋，因而性能達到了最優。
---- 5.總結：
---- 預設情況下建立的索引是非群集索引，但有時它並不是最佳的；合理的索引設計要建立在對各種查詢的分析和預測
上。一般來說：
---- ①.有大量重復值、且經常有范圍查詢
（between, >,< ，>=,< =）和order by
、group by發生的列，可考慮建立群集索引；
---- ②.經常同時存取多列，且每列都含有重復值可考慮建立組合索引；
---- ③.組合索引要盡量使關鍵查詢形成索引覆蓋，其前導列一定是使用最頻繁的列。
二、不充份的連接條件：
---- 例：表card有7896行，在card_no上有一個非聚集索引，表account有191122行，在 account_no上有一個非聚集索引，試看在不同的表連接條件下，兩個SQL的執行情況：
select sum(a.amount) from account a,card b where a.card_no = b.card_no（20秒）
---- 將SQL改為：
select sum(a.amount) from account a,card b where a.card_no = b.card_no and a.account_no=b.account_no（< 1秒）
---- 分析：
---- 在第一個連接條件下，最佳查詢方案是將account作外層表，card作內層表，利用card上的索引，其I/O次數可由以下公式估算為：
---- 外層表account上的22541頁+（外層表account的191122行*內層表card上對應外層表第一行所要查找的3頁）=595907次I/O
---- 在第二個連接條件下，最佳查詢方案是將card作外層表，account作內層表，利用account上的索引，其I/O次數可由以下公式估算為：
---- 外層表card上的1944頁+（外層表card的7896行*內層表account上對應外層表每一行所要查找的4頁）= 33528次I/O
---- 可見，只有充份的連接條件，真正的最佳方案才會被執行。
---- 總結：
---- 1.多表操作在被實際執行前，查詢優化器會根據連接條件，列出幾組可能的連接方案並從中找出系統開銷最小的最佳方案。連接條件要充份考慮帶有索引的表、行數多的表；內外表的選擇可由公式：外層表中的匹配行數*內層表中每一次查找的次數確定，乘積最小為最佳方案。
---- 2.查看執行方案的方法-- 用set showplanon，打開showplan選項，就可以看到連接順序、使用何種索引的信息；想
看更詳細的信息，需用sa角色執行dbcc(3604,310,302)。
三、不可優化的where子句
---- 1.例：下列SQL條件語句中的列都建有恰當的索引，但執行速度卻非常慢：
select * from record where substring(card_no,1,4)='5378'(13秒)
select * from record where amount/30< 1000（11秒）
select * from record where convert(char(10),date,112)='19991201'（10秒）
---- 分析：
---- where子句中對列的任何操作結果都是在SQL運行時逐列計算得到的，因此它不得不進行表搜索，而沒有使用該列上面的索引；如果這些結果在查詢編譯時就能得到，那麼就可以被SQL優化器優化，使用索引，避免表搜索，因此將SQL重寫成
下面這樣：
select * from record where card_no like '5378%'（< 1秒）
select * from record where amount < 1000*30（< 1秒）
select * from record where date= '1999/12/01' （< 1秒）
---- 你會發現SQL明顯快起來！
---- 2.例：表stuff有200000行，id_no上有非群集索引，請看下面這個SQL：
select count(*) from stuff where id_no in('0','1')（23秒）
---- 分析：
---- where條件中的'in'在邏輯上相當於'or'，所以語法分析器會將in ('0','1')轉化為id_no ='0' or id_no='1'來執行。我們期望它會根據每個or子句分別查找，再將結果相加，這樣可以利用id_no上的索引；但實際上（根據showplan）,它卻採用了"OR策略"，即先取出滿足每個or子句的行，存入臨時資料庫的工作表中，再建立唯一索引以去掉重復行，最後從這個臨時表中計算結果。因此，實際過程沒有利用id_no上索引，並且完成時間還要受tempdb資料庫性能的影響。
---- 實踐證明，表的行數越多，工作表的性能就越差，當stuff有620000行時，執行時間竟達到220秒！還不如將or子句分
開：
select count(*) from stuff where id_no='0'
select count(*) from stuff where id_no='1'
---- 得到兩個結果，再作一次加法合算。因為每句都使用了索引，執行時間只有3秒，在620000行下，時間也只有4秒。或者，用更好的方法，寫一個簡單的存儲過程：
create proc count_stuff as
declare @a int
declare @b int
declare @c int
declare @d char(10)
begin
select @a=count(*) from stuff where id_no='0'
select @b=count(*) from stuff where id_no='1'
end
select @c=@a+@b
select @d=convert(char(10),@c)
print @d
---- 直接算出結果，執行時間同上面一樣快！
---- 總結：
---- 可見，所謂優化即where子句利用了索引，不可優化即發生了表掃描或額外開銷。
---- 1.任何對列的操作都將導致表掃描，它包括資料庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。
---- 2.in、or子句常會使用工作表，使索引失效；如果不產生大量重復值，可以考慮把子句拆開；拆開的子句中應該包含索引。
---- 3.要善於使用存儲過程，它使SQL變得更加靈活和高效。
---- 從以上這些例子可以看出，SQL優化的實質就是在結果正確的前提下，用優化器可以識別的語句，充份利用索引，減少表掃描的I/O次數，盡量避免表搜索的發生。其實SQL的性能優化是一個復雜的過程，上述這些只是在應用層次的一種體現，深入研究還會涉及資料庫層的資源配置、網路層的流量控制以及操作系統層的總體設計。