Mysql資料庫引擎-------> MYISAM和INNODB詳解
一、資料庫引擎
資料庫引擎是用於儲存、處理和保護資料的核心服務。利用資料庫引擎可控制訪問許可權並快速處理事務，從而滿足企業內大多數需要處理大量資料的應用程式的要求。 使用資料庫引擎建立用於聯機事務處理或聯機分析處理資料的關係資料庫。這包括建立用於儲存資料的表和用於檢視、管理和保護資料安全的資料庫物件（如索引、檢視和儲存過程）。
二、資料庫引擎任務
在資料庫引擎文件中，各主題的順序遵循用於實現使用資料庫引擎進行資料儲存的系統的任務的主要順序。
- 設計並建立資料庫以儲存系統所需的關係或XML文件
- 實現系統以訪問和更改資料庫中儲存的資料。包括實現網站或使用資料的應用程式，還包括生成使用SQL Server工具和實用工具以使用資料的過程。
- 為單位或客戶部署實現的系統
- 提供日常管理支援以優化資料庫的效能
三、MySQL資料庫引擎類別
你能用的資料庫引擎取決於mysql在安裝的時候是如何被編譯的。要新增一個新的引擎，就必須重新編譯MYSQL。在預設情況下，MYSQL支援三個引擎：ISAM、MYISAM和HEAP。另外兩種型別INNODB和BERKLEY（BDB），也常常可以使用。
ISAM
ISAM是一個定義明確且歷經時間考驗的資料表格管理方法，它在設計之時就考慮到資料庫被查詢的次數要遠大於更新的次數。因此，ISAM執行讀取操作的速度很快，而且不佔用大量的記憶體和儲存資源。ISAM的兩個主要不足之處在於，它不支援事務處理MYISAM
MYISAM是MYSQL的ISAM擴充套件格式和預設的資料庫引擎。除了提供ISAM裡所沒有的索引和欄位管理的功能，MYISAM還使用一種表格鎖定的機制，來優化多個併發的讀寫操作。其代價是你需要經常執行OPTIMIZE TABLE命令，來恢復被更新機制所浪費的空間。MYISAM還有一些有用的擴充套件，例如用來修復資料庫檔案的MYISAMCHK工具和用來恢復浪費空間的MYISAMPACK工具。 MYISAM強調了快速讀取操作，這可能就是為什麼MYSQL受到了WEB開發如此青睞的主要原因：在WEB開發中你所進行的大量資料操作都是讀取操作。所以，大多數虛擬主機提供商和INTERNET平臺提供商只允許使用MYISAM格式。HEAP
INNODB和BERKLEYDB
INNODB和BERKLEYDB（BDB）資料庫引擎都是造就MYSQL靈活性的技術的直接產品，這項技術就是MYSQL++ API。在使用MYSQL的時候，你所面對的每一個挑戰幾乎都源於ISAM和MYISAM資料庫引擎不支援事務處理也不支援外來鍵。儘管要比ISAM和MYISAM引擎慢很多，但是INNODB和BDB包括了對事務處理和外來鍵的支援，這兩點都是前兩個引擎所沒有的。如前所述，如果你的設計需要這些特性中的一者或者兩者，那你就要被迫使用後兩個引擎中的一個了。四、mysql資料引擎更換方式
1、檢視當前資料庫支援的引擎和預設的資料庫引擎：
show engines;
我的查詢結果如下：
2、更改資料庫引擎
2.1、更改方式1：修改配置檔案my.ini
將my-small.ini另存為my.ini，在[mysqld]後面新增default-storage-engine=InnoDB，重啟服務，資料庫預設的引擎修改為InnoDB
2.2、更改方式2:在建表的時候指定
建表時指定：
create table mytbl( id int primary key, name varchar(50) )type=MyISAM;
2.3、更改方式3：建表後更改
alter table mytbl2 type = InnoDB;
3、檢視修改結果
方式1：
show table status from mytest;
方式2：
show create table table_name
五、MyIASM 和 Innodb引擎詳解
Innodb引擎
Innodb引擎提供了對資料庫ACID事務的支援，並且實現了SQL標準的四種隔離級別，關於資料庫事務與其隔離級別的內容請見資料庫事務與其隔離級別這篇文章。該引擎還提供了行級鎖和外來鍵約束，它的設計目標是處理大容量資料庫系統，它本身其實就是基於MySQL後臺的完整資料庫系統，MySQL執行時Innodb會在記憶體中建立緩衝池，用於緩衝資料和索引。但是該引擎不支援FULLTEXT型別的索引，而且它沒有儲存表的行數，當SELECT COUNT(*) FROM TABLE時需要掃描全表。當需要使用資料庫事務時，該引擎當然是首選。由於鎖的粒度更小，寫操作不會鎖定全表，所以在併發較高時，使用Innodb引擎會提升效率。但是使用行級鎖也不是絕對的，如果在執行一個SQL語句時MySQL不能確定要掃描的範圍，InnoDB表同樣會鎖全表。
名詞解析：
ACID
- A 事務的原子性(Atomicity)：指一個事務要麼全部執行,要麼不執行.也就是說一個事務不可能只執行了一半就停止了.比如你從取款機取錢,這個事務可以分成兩個步驟:1劃卡,2出錢.不可能劃了卡,而錢卻沒出來.這兩步必須同時完成.要麼就不完成.
- C 事務的一致性(Consistency)：指事務的執行並不改變資料庫中資料的一致性.例如,完整性約束了a+b=10,一個事務改變了a,那麼b也應該隨之改變.
- I 獨立性(Isolation）:事務的獨立性也有稱作隔離性,是指兩個以上的事務不會出現交錯執行的狀態.因為這樣可能會導致資料不一致.
- D 永續性(Durability）:事務的永續性是指事務執行成功以後,該事務所對資料庫所作的更改便是持久的儲存在資料庫之中，不會無緣無故的回滾.
MyIASM引擎
MyIASM是MySQL預設的引擎，但是它沒有提供對資料庫事務的支援，也不支援行級鎖和外來鍵，因此當INSERT(插入)或UPDATE(更新)資料時即寫操作需要鎖定整個表，效率便會低一些。不過和Innodb不同，MyIASM中儲存了表的行數，於是SELECT COUNT(*) FROM TABLE時只需要直接讀取已經儲存好的值而不需要進行全表掃描。如果表的讀操作遠遠多於寫操作且不需要資料庫事務的支援，那麼MyIASM也是很好的選擇。
兩種引擎的選擇
大尺寸的資料集趨向於選擇InnoDB引擎，因為它支援事務處理和故障恢復。資料庫的大小決定了故障恢復的時間長短，InnoDB可以利用事務日誌進行資料恢復，這會比較快。主鍵查詢在InnoDB引擎下也會相當快，不過需要注意的是如果主鍵太長也會導致效能問題，關於這個問題我會在下文中講到。大批的INSERT語句(在每個INSERT語句中寫入多行，批量插入)在MyISAM下會快一些，但是UPDATE語句在InnoDB下則會更快一些，尤其是在併發量大的時候。
Index——索引
索引（Index）是幫助MySQL高效獲取資料的資料結構。MyIASM和Innodb都使用了樹這種資料結構做為索引。下面我接著講這兩種引擎使用的索引結構，講到這裡，首先應該談一下B-Tree和B+Tree。
MyIASM引擎的索引結構
MyISAM引擎的索引結構為B+Tree，其中B+Tree的資料域儲存的內容為實際資料的地址，也就是說它的索引和實際的資料是分開的，只不過是用索引指向了實際的資料，這種索引就是所謂的非聚集索引。如下圖所示：
這裡設表一共有三列，假設我們以Col1為主鍵，則上圖是一個MyISAM表的主索引（Primary key）示意。可以看出MyISAM的索引檔案僅僅儲存資料記錄的地址。在MyISAM中，主索引和輔助索引（Secondary key）在結構上沒有任何區別，只是主索引要求key是唯一的，而輔助索引的key可以重複。如果我們在Col2上建立一個輔助索引，則此索引的結構如下圖所示：
同樣也是一顆B+Tree，data域儲存資料記錄的地址。因此，MyISAM中索引檢索的演算法為首先按照B+Tree搜尋演算法搜尋索引，如果指定的Key存在，則取出其data域的值，然後以data域的值為地址，讀取相應資料記錄。
Innodb引擎的索引結構
與MyISAM引擎的索引結構同樣也是B+Tree，但是Innodb的索引檔案本身就是資料檔案，即B+Tree的資料域儲存的就是實際的資料，這種索引就是聚集索引。這個索引的key就是資料表的主鍵，因此InnoDB表資料檔案本身就是主索引。
並且和MyISAM不同，InnoDB的輔助索引資料域儲存的也是相應記錄主鍵的值而不是地址，所以當以輔助索引查詢時，會先根據輔助索引找到主鍵，再根據主鍵索引找到實際的資料。所以Innodb不建議使用過長的主鍵，否則會使輔助索引變得過大。建議使用自增的欄位作為主鍵，這樣B+Tree的每一個結點都會被順序的填滿，而不會頻繁的分裂調整，會有效的提升插入資料的效率。
兩者區別：第一個重大區別是InnoDB的資料檔案本身就是索引檔案。從上文知道，MyISAM索引檔案和資料檔案是分離的，索引檔案僅儲存資料記錄的地址。而在InnoDB中，表資料檔案本身就是按B+Tree組織的一個索引結構，這棵樹的葉節點data域儲存了完整的資料記錄。這個索引的key是資料表的主鍵，因此InnoDB表資料檔案本身就是主索引。
上圖是InnoDB主索引（同時也是資料檔案）的示意圖，可以看到葉節點包含了完整的資料記錄。這種索引叫做聚集索引。因為InnoDB的資料檔案本身要按主鍵聚集，所以InnoDB要求表必須有主鍵（MyISAM可以沒有），如果沒有顯式指定，則MySQL系統會自動選擇一個可以唯一標識資料記錄的列作為主鍵，如果不存在這種列，則MySQL自動為InnoDB表生成一個隱含欄位作為主鍵，這個欄位長度為6個位元組，型別為長整形。
第二個與MyISAM索引的不同是InnoDB的輔助索引data域儲存相應記錄主鍵的值而不是地址。換句話說，InnoDB的所有輔助索引都引用主鍵作為data域。例如，下圖為定義在Col3上的一個輔助索引：
這裡以英文字元的ASCII碼作為比較準則。聚集索引這種實現方式使得按主鍵的搜尋十分高效，但是輔助索引搜尋需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然後用主鍵到主索引中檢索獲得記錄。瞭解不同儲存引擎的索引實現方式對於正確使用和優化索引都非常有幫助，例如知道了InnoDB的索引實現後，就很容易明白為什麼不建議使用過長的欄位作為主鍵，因為所有輔助索引都引用主索引，過長的主索引會令輔助索引變得過大。再例如，用非單調(可能是指“非遞增”的意思)的欄位作為主鍵在InnoDB中不是個好主意，因為InnoDB資料檔案本身是一顆B+Tree，非單調(可能是指“非遞增”的意思)的主鍵會造成在插入新記錄時資料檔案為了維持B+Tree的特性而頻繁的分裂調整，十分低效，而使用自增欄位作為主鍵則是一個很好的選擇。
致謝：感謝您的閱讀！
FROM:https://www.cnblogs.com/0201zcr/p/5296843.html