你能用的資料庫引擎取決於mysql在安裝的時候是如何被編譯的。要新增乙個新的引擎，就必須重新編譯mysql。在預設情況下，mysql支援三個引擎：isam、myisam和heap。另外兩種型別innodb和berkley（bdb），也常常可以使用。
isam是乙個定義明確且歷經時間考驗的資料**管理方法，它在設計之時就考慮到資料庫被查詢的次數要遠大於更新的次數。因此，isam執行讀取操作的速度很快，而且不占用大量的記憶體和儲存資源。isam的兩個主要不足之處在於，它不支援事務處理，也不能夠容錯：如果你的硬碟崩潰了，那麼資料檔案就無法恢復了。如果你正在把isam用在關鍵任務應用程式裡，那就必須經常備份你所有的實時資料，通過其複製特性，mysql能夠支援這樣的備份應用程式。
myisam是mysql的isam擴充套件格式和預設的資料庫引擎。除了提供isam裡所沒有的索引和字段管理的大量功能，myisam還使用一種**鎖定的機制，來優化多個併發的讀寫操作。其代價是你需要經常執行optimize table命令，來恢復被更新機制所浪費的空間。myisam還有一些有用的擴充套件，例如用來修復資料庫檔案的myisamchk工具和用來恢復浪費空間的myisampack工具。
myisam強調了快速讀取操作，這可能就是為什麼mysql受到了web開發如此青睞的主要原因：在web開發中你所進行的大量資料操作都是讀取操作。所以，大多數虛擬主機提供商和internet平台提供商只允許使用myisam格式。
heap允許只駐留在記憶體裡的臨時**。駐留在記憶體使得heap比isam和myisam的速度都快，但是它所管理的資料是不穩定的，而且如果在關機之前沒有進行儲存，那麼所有的資料都會丟失。在資料行被刪除的時候，heap也不會浪費大量的空間，heap**在你需要使用select表示式來選擇和操控資料的時候非常有用。要記住，用完**後要刪除**。
innodb和berkleydb（bdb）資料庫引擎都是造就mysql靈活性的技術的直接產品，這項技術就是mysql++ api。在使用mysql的時候，你所面對的每乙個挑戰幾乎都源於isam和myiasm資料庫引擎不支援事務處理也不支援外來鍵。儘管要比isam和myisam引擎慢很多，但是innodb和bdb包括了對事務處理和外來鍵的支援，這兩點都是前兩個引擎所沒有的。如前所述，如果你的設計需要這些特性中的一者或者兩者，那你就要被迫使用後兩個引擎中的乙個了。
innodb引擎提供了對資料庫acid事務的支援，並且實現了sql標準的四種隔離級別，關於資料庫事務與其隔離級別的內容請見資料庫事務與其隔離級別這篇文章。該引擎還提供了行級鎖和外來鍵約束，它的設計目標是處理大容量資料庫系統，它本身其實就是基於mysql後台的完整資料庫系統，mysql執行時innodb會在記憶體中建立緩衝池，用於緩衝資料和索引。但是該引擎不支援fulltext型別的索引，而且它沒有儲存表的行數，當select count(*) from table時需要掃瞄全表。當需要使用資料庫事務時，該引擎當然是首選。由於鎖的粒度更小，寫操作不會鎖定全表，所以在併發較高時，使用innodb引擎會提公升效率。但是使用行級鎖也不是絕對的，如果在執行乙個sql語句時mysql不能確定要掃瞄的範圍，innodb表同樣會鎖全表。
myiasm是mysql預設的引擎，但是它沒有提供對資料庫事務的支援，也不支援行級鎖和外來鍵，因此當insert(插入)或update(更新)資料時即寫操作需要鎖定整個表，效率便會低一些。不過和innodb不同，myiasm中儲存了表的行數，於是select count(*) from table時只需要直接讀取已經儲存好的值而不需要進行全表掃瞄。如果表的讀操作遠遠多於寫操作且不需要資料庫事務的支援，那麼myiasm也是很好的選擇。
大尺寸的資料集趨向於選擇innodb引擎，因為它支援事務處理和故障恢復。資料庫的大小決定了故障恢復的時間長短，innodb可以利用事務日誌進行資料恢復，這會比較快。主鍵查詢在innodb引擎下也會相當快，不過需要注意的是如果主鍵太長也會導致效能問題，關於這個問題我會在下文中講到。大批的insert語句(在每個insert語句中寫入多行，批量插入)在myisam下會快一些，但是update語句在innodb下則會更快一些，尤其是在併發量大的時候。
總結：innodb引擎與myisam 區別
1.前者支援事務；提供資料恢復功能；
2.兩者的索引型別也不一樣。前者為聚族索引，後者非聚族索引；
3.前者支援行級鎖和外來鍵，後者緊支援**鎖；
4.後者行數儲存了表的行數
索引（index）是幫助mysql高效獲取資料的資料結構。myiasm和innodb都使用了樹這種資料結構做為索引，關於樹我也曾經寫過一篇文章樹是一種偉大的資料結構，只是自己的理解，有興趣的朋友可以去閱讀。下面我接著講這兩種引擎使用的索引結構，講到這裡，首先應該談一下b-tree和b+tree。
b+tree是b-tree的變種，那麼我就先講b-tree吧，相信大家都知道紅黑樹，這是我前段時間學《演算法》一書時，實現的一顆紅黑樹，大家可以參考。其實紅黑樹類似2,3-查詢樹，這種樹既有2叉結點又有3叉結點。b-tree也與之類似，它的每個結點做多可以有d個分支（叉），d稱為b-tree的度，如下圖所示，它的每個結點可以有4個元素，5個分支，於是它的度為5。b-tree中的元素是有序的，比如圖中元素7左邊的指標指向的結點中的元素都小於7，而元素7和16之間的指標指向的結點中的元素都處於7和16之間，正是滿足這樣的關係，才能高效的查詢：首先從根節點進行二分查詢，找到就返回對應的值，否則就進入相應的區間結點遞迴的查詢，直到找到對應的元素或找到null指標，找到null指標則表示查詢失敗。這個查詢是十分高效的，其時間複雜度為o(logn)（以d為底，當d很大時，樹的高度就很低），因為每次檢索最多隻需要檢索樹高h個結點。
接下來就該講b+tree了，它是b-tree的變種，如下面兩張圖所示：
從圖中就可以看出，b+tree的內部結點不儲存資料，只儲存指標，而葉子結點則只儲存資料，不儲存指標。並且在其每個葉子節點上增加了乙個指向相鄰葉子節點的指標，這個優化提高區間訪問的效能，比如在第二張圖中要查詢鍵為從18到49的所有資料，當找到18後，只需順著節點和指標順序遍歷就可以一次性訪問到所有資料節點，極大提到了區間查詢效率。
myisam引擎的索引結構為b+tree，其中b+tree的資料域儲存的內容為實際資料的位址，也就是說它的索引和實際的資料是分開的，只不過是用索引指向了實際的資料，這種索引就是所謂的非聚集索引。
myisam引擎的索引結構同樣也是b+tree，但是innodb的索引檔案本身就是資料檔案，即b+tree的資料域儲存的就是實際的資料，這種索引就是聚集索引。這個索引的key就是資料表的主鍵，因此innodb表資料檔案本身就是主索引。
因為innodb的資料檔案本身要按主鍵聚集，所以innodb要求表必須有主鍵（myisam可以沒有），如果沒有顯式指定，則mysql系統會自動選擇乙個可以唯一標識資料記錄的列作為主鍵，如果不存在這種列，則mysql自動為innodb表生成乙個隱含字段作為主鍵，這個字段長度為6個位元組，型別為長整形。
並且和myisam不同，innodb的輔助索引資料域儲存的也是相應記錄主鍵的值而不是位址，所以當以輔助索引查詢時，會先根據輔助索引找到主鍵，再根據主鍵索引找到實際的資料。所以innodb不建議使用過長的主鍵，否則會使輔助索引變得過大。建議使用自增的字段作為主鍵，這樣b+tree的每乙個結點都會被順序的填滿，而不會頻繁的**調整，會有效的提公升插入資料的效率。
mysql資料庫引擎 mysql資料庫引擎
資料庫引擎是用於儲存 處理和保護資料的核心服務。利用資料庫引擎可控制訪問許可權並快速處理事務，從而滿足企業內大多數需要處理大量資料的應用程式的要求。使用資料庫引擎建立用於聯機事務處理或聯機分析處理資料的關聯式資料庫。這包括建立用於儲存資料的表和用於檢視 管理和保護資料安全的資料庫物件 如索引 檢視和...
MySQL資料庫引擎
如果你是個賽車手並且按一下按鈕就能夠立即更換引擎而不需要把車開到車庫裡去換，那會是怎麼感覺呢？mysql資料庫為開發人員所做的就好像是按按鈕換引擎 它讓你選擇資料庫引擎，並給你一條簡單的途徑來切換它。mysql的自帶引擎肯定是夠用了，但是在有些情況下，其他的引擎可能要比手頭所用更適合完成任務。如果願...
mysql資料庫引擎
mysql資料庫引擎 資料庫引擎是在我們編譯安裝mysql的時候確定下來的。也就是說如果我們想換乙個資料庫引擎，也就要重新編譯mysql。我們也可以使用mysql和api來編譯我們自己的資料庫引擎，當然這個是建立在你對資料庫底層非常了解的地步。所以我們想要新增乙個新的資料庫引擎的時候，那麼就編譯吧。...