mysql有哪些存儲引擎
MyISAM、InnoDB、Heap(Memory)、NDB 貌似一般都是使用 InnoDB的，mysql的存儲引擎包括：MyISAM、InnoDB、BDB、MEMORY、MERGE、EXAMPLE、NDBCluster、ARCHIVE、CSV、BLACKHOLE、FEDERATED等，其中InnoDB和BDB提供事務安全表，其他存儲引擎都是非事務安全表。最常使用的2種存儲引擎:1.Myisam是Mysql的默認存儲引擎，當create創建新表時，未指定新表的存儲引擎時，默認使用Myisam。每個MyISAM在磁碟上存儲成三個文件。文件名都和表名相同，擴展名分別是.frm（存儲表定義）、.MYD(MYData，存儲數據)、.MYI(MYIndex，存儲索引)。數據文件和索引文件可以放置在不同的目錄，平均分布io，獲得更快的速度。2.InnoDB存儲引擎提供了具有提交、回滾和崩潰恢復能力的事務安全。但是對比Myisam的存儲引擎，InnoDB寫的處理效率差一些並且會佔用更多的磁碟空間以保留數據和索引。不知道是不是對你有幫助
② MySQL存儲引擎是什麼
MySQL有多種存儲引擎，每種存儲引擎有各自的優缺點，可以擇優選擇使用：
MyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)、EXAMPLE、FEDERATED、ARCHIVE、CSV、BLACKHOLE。
③ Mysql資料庫3種存儲引擎有什麼區別
MySQL常見的三種存儲引擎為InnoDB、MyISAM和MEMORY。其區別體現在事務安全、存儲限制、空間使用、內存使用、插入數據的速度和對外鍵的支持。具體如下：
1、事務安全：
InnoDB支持事務安全，MyISAM和MEMORY兩個不支持。
2、存儲限制：
InnoDB有64TB的存儲限制，MyISAM和MEMORY要是具體情況而定。
3、空間使用：
InnoDB對空間使用程度較高，MyISAM和MEMORY對空間使用程度較低。
4、內存使用：
InnoDB和MEMORY對內存使用程度較高，MyISAM對內存使用程度較低。
5、插入數據的速度：
InnoDB插入數據的速度較低，MyISAM和MEMORY插入數據的速度較高。
6、對外鍵的支持：
InnoDB對外鍵支持情況較好，MyISAM和MEMORY兩個不支持外鍵。
三種引擎特點如下：
1、InnoDB存儲引擎
InnoDB是事務型資料庫的首選引擎，支持事務安全表（ACID），其它存儲引擎都是非事務安全表，支持行鎖定和外鍵，MySQL5.5以後默認使用InnoDB存儲引擎。
InnoDB特點： 支持事務處理，支持外鍵，支持崩潰修復能力和並發控制。如果需要對事務的完整性要求比較高（比如銀行），要求實現並發控制（比如售票），那選擇InnoDB有很大的優勢。
如果需要頻繁的更新、刪除操作的資料庫，也可以選擇InnoDB，因為支持事務的提交（commit）和回滾（rollback）。
2、MyISAM存儲引擎
MyISAM基於ISAM存儲引擎，並對其進行擴展。它是在Web、數據倉儲和其他應用環境下最常使用的存儲引擎之一。MyISAM擁有較高的插入、查詢速度，但不支持事務，不支持外鍵。
MyISAM特點： 插入數據快，空間和內存使用比較低。如果表主要是用於插入新記錄和讀出記錄，那麼選擇MyISAM能實現處理高效率。如果應用的完整性、並發性要求比較低，也可以使用
3、MEMORY存儲引擎
MEMORY存儲引擎將表中的數據存儲到內存中，為查詢和引用其他表數據提供快速訪問。
MEMORY特點： 所有的數據都在內存中，數據的處理速度快，但是安全性不高。如果需要很快的讀寫速度，對數據的安全性要求較低，可以選擇MEMOEY。
它對表的大小有要求，不能建立太大的表。所以，這類資料庫只使用在相對較小的資料庫表。
(3)mysql有哪些存儲引擎擴展閱讀：
mysql其餘不太常見的存儲引擎如下：
1、BDB： 源自Berkeley DB，事務型資料庫的另一種選擇，支持COMMIT和ROLLBACK等其他事務特性
2、Merge ：將一定數量的MyISAM表聯合而成一個整體，在超大規模數據存儲時很有用
3、Archive ：非常適合存儲大量的獨立的，作為歷史記錄的數據。因為它們不經常被讀取。Archive擁有高效的插入速度，但其對查詢的支持相對較差
4、Federated： 將不同的Mysql伺服器聯合起來，邏輯上組成一個完整的資料庫。非常適合分布式應用
5、Cluster/NDB ：高冗餘的存儲引擎，用多台數據機器聯合提供服務以提高整體性能和安全性。適合數據量大，安全和性能要求高的應用
6、CSV： 邏輯上由逗號分割數據的存儲引擎。它會在資料庫子目錄里為每個數據表創建一個.CSV文件。這是一種普通文本文件，每個數據行佔用一個文本行。CSV存儲引擎不支持索引。
7、BlackHole ：黑洞引擎，寫入的任何數據都會消失，一般用於記錄binlog做復制的中繼
④ MySQL簡單介紹——換個角度認識MySQL
1、InnoDB存儲引擎
Mysql版本>=5.5 默認的存儲引擎，MySQL推薦使用的存儲引擎。支持事務，行級鎖定，外鍵約束。事務安全型存儲引擎。更加註重數據的完整性和安全性。
存儲格式 : 數據，索引集中存儲，存儲於同一個表空間文件中。
InnoDB的行鎖模式及其加鎖方法： InnoDB中有以下兩種類型的行鎖：共享鎖（讀鎖： 允許事務對一條行數據進行讀取）和 互斥鎖（寫鎖： 允許事務對一條行數據進行刪除或更新）， 對於update，insert，delete語句，InnoDB會自動給設計的數據集加互斥鎖，對於普通的select語句，InnoDB不會加任何鎖。
InnoDB行鎖的實現方式： InnoDB行鎖是通過給索引上的索引項加鎖來實現的，如果沒有索引，InnoDB將通過隱藏的聚簇索引來對記錄加鎖。InnoDB這種行鎖實現特點意味著：如果不通過索引條件檢索數據，那麼InnoDB將對表中的所有記錄加鎖，實際效果跟表鎖一樣。
（1）在不通過索引條件查詢時，InnoDB會鎖定表中的所有記錄。
（2）Mysql的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果使用相同的索引鍵，是會出現沖突的。
（3）當表有多個索引的時候，不同的事務可以使用不同的索引鎖定不同的行，但都是通過行鎖來對數據加鎖。
優點：
1、支持事務處理、ACID事務特性；
2、實現了SQL標準的四種隔離級別（ 原子性（ Atomicity ）、一致性（ Consistency ）、隔離性（Isolation ）和持續性（Durability ））；
3、支持行級鎖和外鍵約束；
4、可以利用事務日誌進行數據恢復。
5、鎖級別為行鎖，行鎖優點是適用於高並發的頻繁表修改，高並發是性能優於 MyISAM。缺點是系統消耗較大。
6、索引不僅緩存自身，也緩存數據，相比 MyISAM 需要更大的內存。
缺點：
因為它沒有保存表的行數，當使用COUNT統計時會掃描全表。
使用場景：
(1)可靠性要求比較高，或者要求事務；(2)表更新和查詢都相當的頻繁，並且表鎖定的機會比較大的情況。
2、 MyISAM存儲引擎
MySQL<= 5.5 MySQL默認的存儲引擎。ISAM：Indexed Sequential Access Method(索引順序存取方法)的縮寫，是一種文件系統。擅長與處理，高速讀與寫。
功能：
（1）支持數據壓縮存儲,但壓縮後的表變成了只讀表，不可寫；如果需要更新數據，則需要先解壓後更新。
（2）支持表級鎖定，不支持高並發；
（3）支持並發插入。寫操作中的插入操作，不會阻塞讀操作（其他操作）；
優點：
1.高性能讀取；
2.因為它保存了表的行數，當使用COUNT統計時不會掃描全表；
缺點：
1、鎖級別為表鎖，表鎖優點是開銷小，加鎖快；缺點是鎖粒度大，發生鎖沖動概率較高，容納並發能力低，這個引擎適合查詢為主的業務。
2、此引擎不支持事務，也不支持外鍵。
3、INSERT和UPDATE操作需要鎖定整個表；
使用場景：
(1)做很多count 的計算；(2)插入不頻繁，查詢非常頻繁；(3)沒有事務。
InnoDB和MyISAM一些細節上的差別：
1、InnoDB不支持FULLTEXT類型的索引，MySQL5.6之後已經支持（實驗性）。
2、InnoDB中不保存表的 具體行數，也就是說，執行select count() from table時，InnoDB要掃描一遍整個表來計算有多少行，但是MyISAM只要簡單的讀出保存好的行數即可。注意的是，當count()語句包含 where條件時，兩種表的操作是一樣的。
3、對於AUTO_INCREMENT類型的欄位，InnoDB中必須包含只有該欄位的索引，但是在MyISAM表中，可以和其他欄位一起建立聯合索引。
4、DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除。
5、LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，導入數據後再改成InnoDB表，但是對於使用的額外的InnoDB特性（例如外鍵）的表不適用。
6、另外，InnoDB表的行鎖也不是絕對的，如果在執行一個SQL語句時MySQL不能確定要掃描的范圍，InnoDB表同樣會鎖全表。
1．索引概述
利用關鍵字，就是記錄的部分數據（某個欄位，某些欄位，某個欄位的一部分），建立與記錄位置的對應關系，就是索引。索引的關鍵字一定是排序的。索引本質上是表欄位的有序子集，它是提高查詢速度最有效的方法。一個沒有建立任何索引的表，就相當於一本沒有目錄的書，在每次查詢時就會進行全表掃描，這樣會導致查詢效率極低、速度也極慢。如果建立索引，那麼就好比一本添加的目錄，通過目錄的指引，迅速翻閱到指定的章節，提升的查詢性能，節約了查詢資源。
2．索引種類
從索引的定義方式和用途中來看：主鍵索引，唯一索引，普通索引，全文索引。
無論任何類型，都是通過建立關鍵字與位置的對應關系來實現的。索引是通過關鍵字找對應的記錄的地址。
以上類型的差異：對索引關鍵字的要求不同。
關鍵字：記錄的部分數據（某個欄位，某些欄位，某個欄位的一部分）。
普通索引,index：對關鍵字沒有要求。
唯一索引,unique index：要求關鍵字不能重復。同時增加唯一約束。
主鍵索引,primary key：要求關鍵字不能重復，也不能為NULL。同時增加主鍵約束。
全文索引,fulltext key：關鍵字的來源不是所有欄位的數據，而是從欄位中提取的特別關鍵詞。
PS：這里主鍵索引和唯一索引的區別在於：主鍵索引不能為空值，唯一索引允許空值；主鍵索引在一張表內只能創建一個，唯一索引可以創建多個。主鍵索引肯定是唯一索引，但唯一索引不一定是主鍵索引。
3.索引原則
如果索引不遵循使用原則，則可能導致索引無效。
（1）列獨立
如果需要某個欄位上使用索引，則需要在欄位參與的表達中，保證欄位獨立在一側。否則索引不會用到索引, 例如這條sql就不會用到索引:select * from A where id+1=10;
（2）左原則
Like：匹配模式必須要左邊確定不能以通配符開頭。例如:select * from A where name like '%小明%' ，不會用到索引，而select * from A where name like '小明%' 就可以用到索引（name欄位有建立索引），如果業務上需要用到'%小明%'這種方式,有兩種方法:1.可以考慮全文索引,但mysql的全文索引不支持中文；2.只查詢索引列或主鍵列,例如:select name from A where name like '%小明%' 或 select id from A where name like '%小明%' 或 select id,name from A where name like '%小明%' 這三種情況都會用到name的索引;
復合索引：一個索引關聯多個欄位，僅僅針對左邊欄位有效果，添加復合索引時，第一個欄位很重要，只有包含第一個欄位作為查詢條件的情況才會使用復合索引(必須用到建索引時選擇的第一個欄位作為查詢條件,其他欄位的順序無關),而且查詢條件只能出現and拼接,不能用or,否則則無法使用索引.
（3）OR的使用
必須要保證 OR 兩端的條件都存在可以用的索引，該查詢才可以使用索引。
（4）MySQL智能選擇
即使滿足了上面說原則，MySQL也能棄用索引，例如：select * from A where id > 1;這里棄用索引的主要原因：查詢即使使用索引，會導致出現大量的隨機IO，相對於從數據記錄的第一條遍歷到最後一條的順序IO開銷，還要大。
4.索引的使用場景
（1）索引檢索：檢索數據時使用索引。
（2）索引排序: 如果order by 排序需要的欄位上存在索引，則可能使用到索引。
（3）索引覆蓋: 索引擁有的關鍵字內容，覆蓋了查詢所需要的全部數據，此時，就不需要在數據區獲取數據，僅僅在索引區即可。覆蓋就是直接在索引區獲取內容，而不需要在數據區獲取。例如: select name from A where name like '小明%';
建立索引索引時，不能僅僅考慮where檢索，同時考慮其他的使用場景。（在所有的where欄位上增加索引，就是不合理的）
5.前綴索引
前綴索引是建立索引關鍵字一種方案。通常會使用欄位的整體作為索引關鍵字。有時，即使使用欄位前部分數據，也可以去識別某些記錄。就比如一個班級里，我要找王xx，假如姓王的只有1個人，那麼就可以建一個關鍵字為'王'的前綴索引。語法：Index `index_name` (`index_field`(N))使用index_name前N個字元建立的索引。
6.索引失效
（1） 應盡量避免在 where 子句中使用 != 或 > 操作符，否則將引擎放棄使用索引而進行全表掃描；
（2） 應盡量避免在 where 子句中使用 or 來連接條件，如果一個欄位有索引，一個欄位沒有索引，將導致引擎放棄使用索引而進行全表掃描；
（3） 應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描；
（4）應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描；如select id from t where num/2 = 100；
（5） 應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描；如：select id from t where substring(name,1,3) = 』abc』 ；
（6）應盡量避免在where子句中對欄位進行類型轉換，這將導致引擎放棄使用索引而進行全表掃描； 如果列類型是字元串，那一定要在條件中將數據使用引號引用起來,如select id from t where id = 1；如果id欄位在表設計中是varchar類型，那麼即使id列上存的是數字，在查詢時也一定要用varchar去匹配，sql應改為select id from t where id = '1'；
（7）應盡量避免在where子句中單獨引用復合索引里非第一位置的索引；
join 的兩種演算法：BNL 和 NLJ
NLJ（Nested Loop Join）嵌套循環演算法；以如下 SQL 為例：
select * from t1 join t2 on t1.a=t2.a
SQL 執行時內部流程是這樣的：
1. 先從 t1（假設這里 t1 被選為驅動表）中取出一行數據 X；
2. 從 X 中取出關聯欄位 a 值，去 t2 中進行查找，滿足條件的行取出；
3. 重復1、2步驟，直到表 t1 最後一行循環結束。
這就是一個嵌套循環的過程，如果在被驅動表上查找數據時可以使用索引，總的對比計算次數等於驅動表滿足 where 條件的行數。假設這里 t1、t2都是1萬行，則只需要 1萬次計算，這里用到的是Index Nested-Loops Join（INLJ，基於索引的嵌套循環聯接）。
如果 t1、t2 的 a 欄位都沒有索引，還按照上述的嵌套循環流程查找數據呢？每次在被驅動表上查找數據時都是一次全表掃描，要做1萬次全表掃描，掃描行數等於 1萬+1萬*1萬，這個效率很低，如果錶行數更多，掃描行數動輒幾百億，所以優化器肯定不會使用這樣的演算法，而是選擇 BNL 演算法；
BNLJ（Block Nested Loop Join）塊嵌套循環演算法；
1. 把 t1 表（假設這里 t1 被選為驅動表）滿足條件的數據全部取出放到線程的 join buffer 中；
2. 每次取 t2 表一行數據，去 joinbuffer 中進行查找，滿足條件的行取出，直到表 t2 最後一行循環結束。
這個演算法下，執行計劃的 Extra 中會出現 Using join buffer(Block Nested Loop)，t1、t2 都做了一次全表掃描，總的掃描行數等於 1萬+1萬。但是由於 joinbuffer 維護的是一個無序數組，每次在 joinbuffer 中查找都要遍歷所有行，總的內存計算次數等於1萬*1萬。另外如果 joinbuffer 不夠大放不下驅動表的數據，則要分多次執行上面的流程，會導致被驅動表也做多次全表掃描。
BNLJ相對於NLJ的優點在於，驅動層可以先將部分數據載入進buffer，這種方法的直接影響就是將大大減少內層循環的次數，提高join的效率。
例如：
如果內層循環有100條記錄，外層循環也有100條記錄，這樣的話，每次外層循環先將10條記錄放到buffer中，內層循環的100條記錄每條與這個buffer中的10條記錄進行匹配，只需要匹配內層循環總記錄數次即可結束一次循環（在這里，即只需要匹配100次即可結束），然後將匹配成功的記錄連接後放入結果集中，接著，外層循環繼續向buffer中放入10條記錄，同理進行匹配，並將成功的記錄連接後放入結果集。後續循環以此類推，直到循環結束，將結果集發給client為止。
可以發現，若用NLJ，則需要100 * 100次才可結束，BNLJ則需要100 / block_size * 100 = 10 * 100次就可結束,大大減少了循環次數。
JOIN 按照功能大致分為如下三類：
JOIN、STRAIGHT_JOIN、INNER JOIN（內連接,或等值連接）：取得兩個表中存在連接匹配關系的記錄。
LEFT JOIN（左連接）：取得左表（table1）完全記錄，即是右表（table2）並無對應匹配記錄。
RIGHT JOIN（右連接）：與 LEFT JOIN 相反，取得右表（table2）完全記錄，即是左表（table1）並無匹配對應記錄。
注意：mysql不支持Full join,不過可以通過UNION 關鍵字來合並 LEFT JOIN 與 RIGHT JOIN來模擬FULL join。
mysql 多表連接查詢方式，因為mysql只支持NLJ演算法,所以如果是小表驅動大表則效率更高；反之則效率下降；因此mysql對內連接或等值連接的方式做了一個優化,會去判斷join表的數據行大小,然後取數據行小的表為驅動表。
INNER JOIN、JOIN、WHERE等值連接和STRAIGHT_JOIN都能表示內連接，那平時如何選擇呢？一般情況下用INNER JOIN、JOIN或者WHERE等值連接，因為MySQL 會按照"小表驅動大表的策略"進行優化。當出現需要排序時，才考慮用STRAIGHT_JOIN指定某張表為驅動表。
兩表JOIN優化
a.當無order by條件時，根據實際情況，使用left/right/inner join即可，根據explain優化 ；
b.當有order by條件時，如select * from a inner join b where 1=1 and other condition order by a.col；使用explain解釋語句；
1）如果第一行的驅動表為a，則效率會非常高，無需優化；
2）否則，因為只能對驅動表欄位直接排序的緣故，會出現using temporary，所以此時需要使用STRAIGHT_JOIN明確a為驅動表，來達到使用a.col上index的優化目的；或者使用left join且Where條件中不含b的過濾條件，此時的結果集為a的全集，而STRAIGHT_JOIN為inner join且使用a作為驅動表。註：使用STRAIGHT_JOIN雖然不會using temporary，但也不是一定就能提高效率，如果a表數據遠遠超過b表，那麼有可能使用STRAIGHT_JOIN時比原來的sql效率更低，所以怎麼使用STRAIGHT_JOIN，還是要視情況而定。
在使用left join（或right join）時，應該清楚的知道以下幾點：
(1). on與 where的執行順序
ON 條件（「A LEFT JOIN B ON 條件表達式」中的ON）用來決定如何從 B 表中檢索數據行。如果 B 表中沒有任何一行數據匹配 ON 的條件,將會額外生成一行所有列為 NULL 的數據,在匹配階段 WHERE 子句的條件都不會被使用。僅在匹配階段完成以後，WHERE 子句條件才會被使用。它將從匹配階段產生的數據中檢索過濾。
所以我們要注意：在使用Left (right) join的時候，一定要在先給出盡可能多的匹配滿足條件，減少Where的執行。
(2).注意ON 子句和 WHERE 子句的不同
即使右表的數據不滿足ON後面的條件,也會在結果集拼接一條為NULL的數據行,但WHERE後面的條件不一樣,右表不滿足WHERE的條件,左表關聯的數據也會被過濾掉。
(3).盡量避免子查詢，而用join
往往性能這玩意兒，更多時候體現在數據量比較大的時候，此時，我們應該避免復雜的子查詢。
（1）in 和 not in 要慎用，如：select id from t where num in(1,2,3)對於連續的數值，能用 between 就不要用 in：select id from t where num between 1 and 3很多時候用 exists 代替 in 是一個好的選擇：select num from a where num in(select num from b)用下面的語句替換：select num from a where exists(select 1 from b where num=a.num)
（2）Update 語句，如果只更改1、2個欄位，不要Update全部欄位，否則頻繁調用會引起明顯的性能消耗，同時帶來大量日誌。
（3）join語句,MySQL裡面的join是用小表去驅動大表,而由於MySQL join實現的原理就是做循環，比如left join就是對左邊的數據進行循環去驅動右邊的表,左邊有m條記錄匹配,右邊有n條記錄那麼就是做m次循環,每次掃描n行數據,總掃面行數是m*n行數據。左邊返回的結果集的大小就決定了循環的次數,故單純的用小表去驅動大表不一定的正確的,小表的結果集可能也大於大表的結果集,所以寫join的時候盡可能的先估計兩張表的可能結果集,用小結果集去驅動大結果集.值得注意的是在使用left/right join的時候,從表的條件應寫在on之後,主表應寫在where之後.否則MySQL會當作普通的連表查詢；
（4）select count(*) from table；這樣不帶任何條件的count會引起全表掃描，並且沒有任何業務意義，是一定要杜絕的；
（5）select * from t 這種語句要盡量避免，使用具體的欄位代替*，更有實際意義，需要什麼欄位就返回什麼欄位；
（6）數據量大的情況下，limit要慎用，因為使用limit m，n方式分頁時，mysql每次都是查詢前m+n條，然後舍棄前m條，所以m越大，偏移量越大，性能就越差。比如：select * from A limit 1000000,20這鍾，查詢效率就會非常低，當分頁的頁數大於一定的數量之後，就可以換種方式來分頁：select * from A a join （select id from A limit 1000000，20） b on a.id=b.id;
⑤ mysql有哪些存儲引擎
(一)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的存儲引擎有兩個
在MySQL 5.1之前的版本中，默認的存儲引擎是MyISAM，
在MySQL 5.5之後的版本中，默認的存儲引擎是InnoDB
⑦ 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個常見的存儲引擎。使用哪一種引擎需要靈活選擇，一個資料庫中多個表可以使用不同引擎以滿足各種性能和實際需求，使用合適的存儲引擎，將會提高整個資料庫的性能
⑧ 什麼是MySQL存儲引擎
MySQL 可能是最著名的 關系資料庫管理系統 (RDBMS),作為一款免費開源軟體開發，最初由 MYSQL AB 公司提供支持，但現在歸 Oracle 所有。
在 MySQL 中，用於表的「存儲引擎」決定了數據的處理方式。有幾種可用的存儲引擎，但最常用的是 InnoDB 和 MyISAM 。
在本文中，我們將了解它們的顯著特徵以及它們之間的主要區別。
在本教程中，您將學習：
在我們討論兩個主要 MySQL 存儲引擎之間的特性和區別之前，先來了解一下什麼是存儲引擎？
存儲引擎，也稱為「 表處理程序 」，基本上是解釋和管理與資料庫表的 SQL 查詢相關的操作的資料庫部分。
在最新版本的 MySQL 中，可以使用「 可插拔 」架構來組織和管理存儲引擎，存在多種存儲引擎，但最常用的兩個是 InnoDB 和 MyISAM 。
要獲得我們正在使用的資料庫中可用存儲引擎的列表，我們所要做的就是發出一個簡單的 SQL 查詢，因此我們需要做的第一件事就是打開一個 MySQL 互動式提示並使用資料庫用戶登錄及其密碼：
如果登錄成功，提示將變為mysql>，在這里，我們可以運行我們的 SQL 查詢來可視化可用的存儲引擎：
執行查詢後，我們應該獲得類似於以下內容的結果：
在上表中，作為查詢結果生成，我們可以通過查看Support每行列中的值輕鬆了解支持哪些存儲引擎，「YES」值表示存儲引擎可用，否則「NO」。相反，同一列中的「DEFAULT」值表示相應的引擎（在本例中為 InnoDB）是伺服器使用的默認引擎。
「 Transactions 」和「 Savepoints 」列中存在的值分別表示存儲引擎是否支持事務和回滾。正如我們通過查看錶可以看到的，只有 InnoDB 引擎可以。
關於存儲引擎的信息存在於「 INFORMATION_SCHEMA 」資料庫的「 ENGINES 」表中，因此我們也可以發出標準的「SELECT」查詢來獲取我們需要的數據：
我們將獲得與上面看到的相同的結果。
讓我們看看兩個最常用的存儲引擎 InnoDB 和 MyISAM 之間的主要特性和區別是什麼。
正如我們已經說過的， InnoDB 是自 MySQL 以來的默認存儲引擎5.5。
此存儲引擎的一些主要功能如下：
對事務的支持提供了一種安全的方式來執行多個查詢以保持數據一致。
當多個修改數據的操作被執行並且我們想要確保它們只有在所有操作都成功並且沒有錯誤發生時才有效時，我們想要使用事務。
典型的處理方式是啟動事務並執行查詢：如果出現錯誤，則執行回滾，否則提交更改。
當使用 InnoDB 數據鎖定發生在行級別時，因此在事務期間鎖定的數據量是有限的。
InnoDB 有兩種類型的鎖：
一個共享鎖允許誰擁有它讀取該行的交易，而一個排它鎖允許交易執行其修改行的操作，所以要更新或刪除數據。
當一個事務在某行上獲得共享鎖，而另一個事務需要相同的鎖類型時，立即授予；但是，如果第二個事務在同一行上請求排他鎖，它將不得不等待。
如果第一個事務持有該行的排他鎖，則第二個事務將不得不等待該鎖被釋放以獲得共享鎖或排他鎖。
外鍵是一個非常重要的特性，因為它們可用於基於表之間的邏輯關系來強制執行數據完整性。想像一下，我們的資料庫中有三個表（假設它被稱為「testdb」）：一個user包含現有用戶的job表，一個注冊所有可用作業的user_job表，以及一個用於表示用戶和用戶之間存在的多對多關系的表。作業（一個用戶可以有多個作業，多個作業可以與同一個用戶關聯）。
該user_job表就是所謂的連接表或關聯表，因為它的唯一目的是表示用戶-工作關聯。該表有兩列，一個叫user_id和其他job id。表中會存在兩個外鍵約束，強制執行以下規則：user_id列中的值只能引用表id列中的值，列中的user值job_id必須引用表id列中的現有值job.
這將強制執行完整性，因為僅允許現有用戶和作業的 ID 存在於關聯表中。刪除涉及表中一個或多個關聯的用戶或作業user_job也是不允許的，除非為相應的外鍵設置了CASCADE DELETE規則。在這種情況下，當刪除用戶或作業時，它們所涉及的關系也將被刪除。
MyISAM 曾經是默認的 MySQL 存儲引擎，但已被 InnoDB 取代。使用此引擎時，數據鎖定發生在表級別，因此執行操作時鎖定的數據更多。
與 InnoDB 不同，MyISAM 不支持事務回滾和提交，因此必須手動執行回滾。MyISAM 和 InnoDB 之間的另一個很大區別是前者不支持外鍵。MyISAM 更簡單，並且在對有限數據集進行讀取密集型操作時可能具有優勢（有爭議）。
在表上使用 MyISAM 時，會設置一個標志，指示該表是否需要修復，例如在突然關閉之後。稍後可以使用適當的工具執行表修復。
如何知道特定表使用了什麼存儲引擎？我們所要做的就是發出一個簡單的查詢。
例如，要知道user我們在前面的例子中提到的表使用了什麼存儲引擎，我們將運行：
注意上面的查詢我們使用了G，為了讓查詢結果垂直顯示，優化空間。執行查詢後，我們將獲得以下結果：
在這種情況下，通過查看「Engine」列中存儲的值，我們可以清楚地看到該表使用的是「InnoDB」引擎。獲取相同信息的另一種方法是INFORMATION_SCHEMA.TABLES直接查詢表：
上面的查詢將只返回表使用的引擎：
如果我們稍微更改查詢，我們可以獲得資料庫中所有表名的列表以及它們使用的引擎：
如果我們要為一個表設置一個特定的存儲引擎，我們可以在創建時指定它。例如，假設我們正在創建job表，並且出於某種原因我們想要使用 MyISAM 存儲引擎。我們將發出以下 SQL 查詢：
相反，如果我們想要更改用於已存在表的存儲引擎，我們只需要使用ALTERSQL 語句。假設我們要將上一個示例中創建的「job」表所使用的存儲引擎更改為 InnoDB；我們會運行：
在本教程中，我們學習了什麼是資料庫存儲引擎，並且我們看到了兩個最常用的 MySQL 引擎的主要特性： InnoDB 和 MyISAM 。
我們看到了如何檢查哪些引擎可用、哪些引擎用於表以及如何使用 SQL 查詢設置和修改表引擎。
⑨ MySQL存儲引擎
InnoDB的數據文件本身就是主索引文件。而MyISAM的主索引和數據是分開的。輔助索引data域存儲相應記錄主鍵的值而不是地址。
innoDB是聚簇索引，數據掛在逐漸索引之下。
是 MySQL 默認的事務型存儲引擎， 只有在需要它不支持的特性時，才考慮使用其它存儲引擎 。
實現了四個標準的隔離級別，默認級別是可重復讀(REPEATABLE READ)。在可重復讀隔離級別下，通過多版本並發控制(MVCC)+ 間隙鎖(Next-Key Locking)防止幻影讀。
主索引是聚簇索引，在索引中保存了數據，從而避免直接讀取磁碟，因此對查詢性能有很大的提升。
內部做了很多優化，包括從磁碟讀取數據時採用的可預測性讀、能夠加快讀操作並且自動創建的自適應哈希索引、能夠加速插入操作的插入緩沖區等。
支持真正的在線熱備份。其它存儲引擎不支持在線熱備份，要獲取一致性視圖需要停止對所有表的寫入，而在讀寫混合場景中，停止寫入可能也意味著停止讀取。
以B+樹作為索引結構，葉節點的數據域存放數據記錄的地址。主索引和輔助索引在結構上沒有區別，只是主索引要求key唯一，而輔助索引的key可以重復。
MyISAM中索引檢索的演算法為首先按照B+Tree搜索演算法搜索索引，如果指定的Key存在，則取出其data域的值，然後以data域的值為地址，讀取相應數據記錄。
設計簡單，數據以緊密格式存儲。對於只讀數據，或者表比較小、可以容忍修復的操作，則依然可以使用它。
提供了大量的特性，包括壓縮表、空間數據索引等。
不支持事務 。
不支持行級鎖，只能對整張表加鎖，讀取時會對需要讀到的所有表加共享鎖，寫入時則對表加排它鎖。但在表有讀取操作的同時，也可以往表中插入新的記錄，這被稱為並發插入(CONCURRENT INSERT)。
可以手工或者自動執行檢查和修復操作，但是和事務恢復以及崩潰恢復不同，可能導致一些數據丟失，而且修復操作是非常慢的。
如果指定了 DELAY_KEY_WRITE 選項，在每次修改執行完成時，不會立即將修改的索引數據寫入磁碟，而是會寫到內存中的鍵緩沖區，只有在清理鍵緩沖區或者關閉表的時候才會將對應的索引塊寫入磁碟。這種方式可以極大地提升寫入性能，但是在資料庫或者主機崩潰時會造成索引損壞，需要執行修復操作。