一張表，裡面有ID自增主鍵，當insert了17條記錄之後，删除了第15,16,17條記錄，再把Mysql重新開機，再insert一條記錄，這條記錄的ID是18還是15 ？
1.如果表的類型是MyISAM，那麼是18 因為MyISAM表會把自增主鍵的最大ID記錄到資料檔案裡，重新開機MySQL自增主鍵的最大ID也不會丢失2.如果表的類型是InnoDB，那麼是15 InnoDB表隻是把自增主鍵的最大ID記錄到記憶體中，是以重新開機資料庫或者是對表進行OPTIMIZE操作，都會導緻最大ID丢失
innodb和myisam對比
InnoDB和MyISAM是很多人在使用MySQL時最常用的兩個表類型，這兩個表類型各有優劣，5.7之後就不一樣了
事務和外鍵
InnoDB具有事務，支援4個事務隔離級别，復原，崩潰修複能力和多版本并發的事務安全，包括ACID。如果應用中需要執行大量的INSERT或UPDATE操作，則應該使用InnoDB，這樣可以提高多使用者并發操作的性能
MyISAM管理非事務表。它提供高速存儲和檢索，以及全文搜尋能力。如果應用中需要執行大量的SELECT查詢，那麼MyISAM是更好的選擇
全文索引
Innodb不支援全文索引，如果一定要用的話，最好使用sphinx等搜尋引擎。myisam對中文支援的不是很好
不過新版本的Innodb已經支援了
鎖
mysql支援三種鎖定級别，行級、頁級、表級;
MyISAM支援表級鎖定，提供與 Oracle 類型一緻的不加鎖讀取(non-locking read in SELECTs)
InnoDB支援行級鎖，InnoDB表的行鎖也不是絕對的，如果在執行一個SQL語句時MySQL不能确定要掃描的範圍，InnoDB表同樣會鎖全表，注意間隙鎖的影響
例如update table set num=1 where name like “%aaa%”
存儲
MyISAM在磁盤上存儲成三個檔案。第一個檔案的名字以表的名字開始，擴充名指出檔案類型， .frm檔案存儲表定義，資料檔案的擴充名為.MYD， 索引檔案的擴充名是.MYI
InnoDB，基于磁盤的資源是InnoDB表空間資料檔案和它的日志檔案，InnoDB 表的大小隻受限于作業系統檔案的大小
注意：MyISAM表是儲存成檔案的形式，在跨平台的資料轉移中使用MyISAM存儲會省去不少的麻煩
索引
InnoDB（索引組織表）使用的聚簇索引、索引就是資料，順序存儲，是以能緩存索引，也能緩存資料
MyISAM（堆組織表）使用的是非聚簇索引、索引和檔案分開，随機存儲，隻能緩存索引
并發
MyISAM讀寫互相阻塞：不僅會在寫入的時候阻塞讀取，MyISAM還會在讀取的時候阻塞寫入，但讀本身并不會阻塞另外的讀
InnoDB 讀寫阻塞與事務隔離級别相關
場景選擇
MyISAM
1.不需要事務支援（不支援）2.并發相對較低（鎖定機制問題）3.資料修改相對較少（阻塞問題），以讀為主4.資料一緻性要求不是非常高 盡量索引（緩存機制） 調整讀寫優先級，根據實際需求確定重要操作更優先 啟用延遲插入改善大批量寫入性能 盡量順序操作讓insert資料都寫入到尾部，減少阻塞 分解大的操作，降低單個操作的阻塞時間 降低并發數，某些高并發場景通過應用來進行排隊機制 對于相對靜态的資料，充分利用Query Cache可以極大的提高通路效率 MyISAM的Count隻有在全表掃描的時候特别高效，帶有其他條件的count都需要進行實際的資料通路
InnoDB
•需要事務支援（具有較好的事務特性）•行級鎖定對高并發有很好的适應能力，但需要確定查詢是通過索引完成•資料更新較為頻繁的場景•資料一緻性要求較高•硬體裝置記憶體較大，可以利用InnoDB較好的緩存能力來提高記憶體使用率，盡可能減少磁盤 IO 主鍵盡可能小，避免給Secondary index帶來過大的空間負擔 避免全表掃描，因為會使用表鎖 盡可能緩存所有的索引和資料，提高響應速度 在大批量小插入的時候，盡量自己控制事務而不要使用autocommit自動送出 合理設定innodb_flush_log_at_trx_commit參數值，不要過度追求安全性 避免主鍵更新，因為這會帶來大量的資料移動
其它細節
•InnoDB 中不儲存表的具體行數，注意的是，當count(*)語句包含 where條件時，兩種表的操作是一樣的•對于AUTO_INCREMENT類型的字段，InnoDB中必須包含隻有該字段的索引，但是在MyISAM表中，可以和其他字段一起建立聯合索引， 如果你為一個表指定AUTO_INCREMENT列，在資料詞典裡的InnoDB表句柄包含一個名為自動增長計數器的計數器，它被用在為該列賦新值。自動增長計數器僅被存儲在主記憶體中，而不是存在磁盤•DELETE FROM table時，InnoDB不會重建立立表，而是一行一行的删除•LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，導入資料後再改成InnoDB表，但是對于使用的額外的InnoDB特性(例如外鍵)的表不适用•如果執行大量的SELECT，MyISAM是更好的選擇，如果你的資料執行大量的INSERT或UPDATE，出于性能方面的考慮，應該使用InnoDB表
為什麼MyISAM會比Innodb 的查詢速度快
InnoDB 在做SELECT的時候，要維護的東西比MYISAM引擎多很多；
1.InnoDB 要緩存資料和索引，MyISAM隻緩存索引塊，這中間還有換進換出的減少2.innodb尋址要映射到塊，再到行，MyISAM記錄的直接是檔案的OFFSET，定位比INNODB要快3.InnoDB 還需要維護MVCC一緻；雖然你的場景沒有，但他還是需要去檢查和維護
MVCC ( Multi-Version Concurrency Control )多版本并發控制
InnoDB ：通過為每一行記錄添加兩個額外的隐藏的值來實作MVCC，這兩個值一個記錄這行資料何時被建立，另外一個記錄這行資料何時過期（或者被删除）。但是InnoDB并不存儲這些事件發生時的實際時間，相反它隻存儲這些事件發生時的系統版本号。這是一個随着事務的建立而不斷增長的數字。每個事務在事務開始時會記錄它自己的系統版本号。每個查詢必須去檢查每行資料的版本号與事務的版本号是否相同。讓我們來看看當隔離級别是REPEATABLE READ時這種政策是如何應用到特定的操作的
SELECT InnoDB必須每行資料來保證它符合兩個條件
1.InnoDB必須找到一個行的版本，它至少要和事務的版本一樣老(也即它的版本号不大于事務的版本号)。這保證了不管是事務開始之前，或者事務建立時，或者修改了這行資料的時候，這行資料是存在的。2.這行資料的删除版本必須是未定義的或者比事務版本要大。這可以保證在事務開始之前這行資料沒有被删除。
mysql性能讨論
MyISAM最為人垢病的缺點就是缺乏事務的支援
InnoDB 的磁盤性能很令人擔心
MySQL 缺乏良好的 tablespace
兩種類型最主要的差别就是Innodb 支援事務處理與外鍵和行級鎖.而MyISAM不支援.是以MyISAM往往就容易被人認為隻适合在小項目中使用。
我作為使用MySQL的使用者角度出發，Innodb和MyISAM都是比較喜歡的，但是從我目前運維的資料庫平台要達到需求：99.9%的穩定性，友善的擴充性和高可用性來說的話，MyISAM絕對是我的首選。
原因如下：
1.首先我目前平台上承載的大部分項目是讀多寫少的項目，而MyISAM的讀性能是比Innodb強不少的。2.MyISAM的索引和資料是分開的，并且索引是有壓縮的，記憶體使用率就對應提高了不少。能加載更多索引，而Innodb是索引和資料是緊密捆綁的，沒有使用壓縮進而會造成Innodb比MyISAM體積龐大不小。3.從平台角度來說，經常隔1，2個月就會發生應用開發人員不小心update一個表where寫的範圍不對，導緻這個表沒法正常用了，這個時候MyISAM的優越性就展現出來了，随便從當天拷貝的壓縮包取出對應表的檔案，随便放到一個資料庫目錄下，然後dump成sql再導回到主庫，并把對應的binlog補上。如果是Innodb，恐怕不可能有這麼快速度，别和我說讓Innodb定期用導出xxx.sql機制備份，因為我平台上最小的一個資料庫執行個體的資料量基本都是幾十G大小。4.從我接觸的應用邏輯來說，select count(*) 和order by 是最頻繁的，大概能占了整個sql總語句的60%以上的操作，而這種操作Innodb其實也是會鎖表的，很多人以為Innodb是行級鎖，那個隻是where對它主鍵是有效，非主鍵的都會鎖全表的。5.還有就是經常有很多應用部門需要我給他們定期某些表的資料，MyISAM的話很友善，隻要發給他們對應那表的frm.MYD,MYI的檔案，讓他們自己在對應版本的資料庫啟動就行，而Innodb就需要導出xxx.sql了，因為光給别人檔案，受字典資料檔案的影響，對方是無法使用的。6.如果和MyISAM比insert寫操作的話，Innodb還達不到MyISAM的寫性能，如果是針對基于索引的update操作，雖然MyISAM可能會遜色Innodb,但是那麼高并發的寫，從庫能否追的上也是一個問題，還不如通過多執行個體分庫分表架構來解決。7.如果是用MyISAM的話，merge引擎可以大大加快應用部門的開發速度，他們隻要對這個merge表做一些select count(*)操作，非常适合大項目總量約幾億的rows某一類型(如日志，調查統計)的業務表。
當然Innodb也不是絕對不用，用事務的項目如模拟炒股項目，我就是用Innodb的，活躍使用者20多萬時候，也是很輕松應付了，是以我個人也是很喜歡Innodb的，隻是如果從資料庫平台應用出發，我還是會首選MyISAM。
另外，可能有人會說你MyISAM無法抗太多寫操作，但是我可以通過架構來彌補，說個我現有用的資料庫平台容量：主從資料總量在幾百T以上，每天十多億 pv的動态頁面，還有幾個大項目是通過資料接口方式調用未算進pv總數，(其中包括一個大項目因為初期memcached沒部署,導緻單台資料庫每天處理 9千萬的查詢)。而我的整體資料庫伺服器平均負載都在0.5-1左右。
MyISAM索引實作
MyISAM引擎使用B+Tree作為索引結構，葉節點的data域存放的是資料記錄的位址。如圖：
這裡設表一共有三列，假設我們以Col1為主鍵，則上圖是一個MyISAM表的主索引（Primary key）示意。可以看出MyISAM的索引檔案僅僅儲存資料記錄的位址。在MyISAM中，主索引和輔助索引（Secondary key）在結構上沒有任何差別，隻是主索引要求key是唯一的，而輔助索引的key可以重複。如果我們在Col2上建立一個輔助索引，則此索引的結構如下圖所示：
同樣也是一顆B+Tree，data域儲存資料記錄的位址。是以，MyISAM中索引檢索的算法為首先按照B+Tree搜尋算法搜尋索引，如果指定的Key存在，則取出其data域的值，然後以data域的值為位址，讀取相應資料記錄。MyISAM的索引方式也叫做“非聚集”的，之是以這麼稱呼是為了與InnoDB的聚集索引區分。
InnoDB索引實作
雖然InnoDB也使用B+Tree作為索引結構，但具體實作方式卻與MyISAM截然不同。
第一個重大差別是InnoDB的資料檔案本身就是索引檔案。從上文知道，MyISAM索引檔案和資料檔案是分離的，索引檔案僅儲存資料記錄的位址。而在InnoDB中，表資料檔案本身就是按B+Tree組織的一個索引結構，這棵樹的葉節點data域儲存了完整的資料記錄。這個索引的key是資料表的主鍵，是以InnoDB表資料檔案本身就是主索引。
上圖是InnoDB主索引（同時也是資料檔案）的示意圖，可以看到葉節點包含了完整的資料記錄。這種索引叫做聚集索引。因為InnoDB的資料檔案本身要按主鍵聚集，是以InnoDB要求表必須有主鍵（MyISAM可以沒有），如果沒有顯式指定，則MySQL系統會自動選擇一個可以唯一辨別資料記錄的列作為主鍵，如果不存在這種列，則MySQL自動為InnoDB表生成一個隐含字段作為主鍵，這個字段長度為6個位元組，類型為長整形。
第二個與MyISAM索引的不同是InnoDB的輔助索引data域存儲相應記錄主鍵的值而不是位址。換句話說，InnoDB的所有輔助索引都引用主鍵作為data域。例如，下圖為定義在Col3上的一個輔助索引：