一張表，里面有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上的一個輔助索引：

這里以英文字符的ASCII碼作為比較準則。聚集索引這種實現方式使得按主鍵的搜索十分高效，但是輔助索引搜索需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然后用主鍵到主索引中檢索獲得記錄。

總結

在數據庫開發中，了解不同存儲引擎的索引實現方式對于正確使用和優化索引都非常有幫助。例如，知道了InnoDB的索引實現后，就很容易明白為什么不建議使用過長的字段作為主鍵，因為所有輔助索引都引用主索引，過長的主索引會令輔助索引變得過大。再例如，用非單調的字段作為主鍵在InnoDB中不是個好做法，因為InnoDB數據文件本身是一顆B+Tree，非單調的主鍵會造成在插入新記錄時數據文件為了維持B+Tree的特性而頻繁的分裂調整，十分低效，而使用自增字段作為主鍵則是一個很好的選擇。

面試題積累 https://www.cnblogs.com/skyme/p/13212296.html

微服務架構微信交流群

?

總結

以上是生活随笔為你收集整理的dataframe在特定列 插入_从插入看mysql存储引擎的区别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。