一張表，里面有ID自增主鍵，當(dāng)insert了17條記錄之后，刪除了第15,16,17條記錄，再把Mysql重啟，再insert一條記錄，這條記錄的ID是18還是15 ？

1.如果表的類型是MyISAM，那么是18 因為MyISAM表會把自增主鍵的最大ID記錄到數(shù)據(jù)文件里，重啟MySQL自增主鍵的最大ID也不會丟失2.如果表的類型是InnoDB，那么是15 InnoDB表只是把自增主鍵的最大ID記錄到內(nèi)存中，所以重啟數(shù)據(jù)庫或者是對表進行OPTIMIZE操作，都會導(dǎo)致最大ID丟失

innodb和myisam對比

InnoDB和MyISAM是很多人在使用MySQL時最常用的兩個表類型，這兩個表類型各有優(yōu)劣，5.7之后就不一樣了

事務(wù)和外鍵

InnoDB具有事務(wù)，支持4個事務(wù)隔離級別，回滾，崩潰修復(fù)能力和多版本并發(fā)的事務(wù)安全，包括ACID。如果應(yīng)用中需要執(zhí)行大量的INSERT或UPDATE操作，則應(yīng)該使用InnoDB，這樣可以提高多用戶并發(fā)操作的性能

MyISAM管理非事務(wù)表。它提供高速存儲和檢索，以及全文搜索能力。如果應(yīng)用中需要執(zhí)行大量的SELECT查詢，那么MyISAM是更好的選擇

全文索引

Innodb不支持全文索引，如果一定要用的話，最好使用sphinx等搜索引擎。myisam對中文支持的不是很好

不過新版本的Innodb已經(jīng)支持了

鎖

mysql支持三種鎖定級別，行級、頁級、表級;

MyISAM支持表級鎖定，提供與 Oracle 類型一致的不加鎖讀取(non-locking read in SELECTs)

InnoDB支持行級鎖，InnoDB表的行鎖也不是絕對的，如果在執(zhí)行一個SQL語句時MySQL不能確定要掃描的范圍，InnoDB表同樣會鎖全表，注意間隙鎖的影響

例如update table set num=1 where name like “%aaa%”

存儲

MyISAM在磁盤上存儲成三個文件。第一個文件的名字以表的名字開始，擴展名指出文件類型， .frm文件存儲表定義，數(shù)據(jù)文件的擴展名為.MYD， 索引文件的擴展名是.MYI

InnoDB，基于磁盤的資源是InnoDB表空間數(shù)據(jù)文件和它的日志文件，InnoDB 表的大小只受限于操作系統(tǒng)文件的大小

注意：MyISAM表是保存成文件的形式，在跨平臺的數(shù)據(jù)轉(zhuǎn)移中使用MyISAM存儲會省去不少的麻煩

索引

InnoDB(索引組織表)使用的聚簇索引、索引就是數(shù)據(jù)，順序存儲，因此能緩存索引，也能緩存數(shù)據(jù)

MyISAM(堆組織表)使用的是非聚簇索引、索引和文件分開，隨機存儲，只能緩存索引

并發(fā)

MyISAM讀寫互相阻塞：不僅會在寫入的時候阻塞讀取，MyISAM還會在讀取的時候阻塞寫入，但讀本身并不會阻塞另外的讀

InnoDB 讀寫阻塞與事務(wù)隔離級別相關(guān)

場景選擇

MyISAM

1.不需要事務(wù)支持(不支持)2.并發(fā)相對較低(鎖定機制問題)3.數(shù)據(jù)修改相對較少(阻塞問題)，以讀為主4.數(shù)據(jù)一致性要求不是非常高 盡量索引(緩存機制) 調(diào)整讀寫優(yōu)先級，根據(jù)實際需求確保重要操作更優(yōu)先 啟用延遲插入改善大批量寫入性能 盡量順序操作讓insert數(shù)據(jù)都寫入到尾部，減少阻塞 分解大的操作，降低單個操作的阻塞時間 降低并發(fā)數(shù)，某些高并發(fā)場景通過應(yīng)用來進行排隊機制 對于相對靜態(tài)的數(shù)據(jù)，充分利用Query Cache可以極大的提高訪問效率 MyISAM的Count只有在全表掃描的時候特別高效，帶有其他條件的count都需要進行實際的數(shù)據(jù)訪問

InnoDB

?需要事務(wù)支持(具有較好的事務(wù)特性)?行級鎖定對高并發(fā)有很好的適應(yīng)能力，但需要確保查詢是通過索引完成?數(shù)據(jù)更新較為頻繁的場景?數(shù)據(jù)一致性要求較高?硬件設(shè)備內(nèi)存較大，可以利用InnoDB較好的緩存能力來提高內(nèi)存利用率，盡可能減少磁盤 IO 主鍵盡可能小，避免給Secondary index帶來過大的空間負擔(dān) 避免全表掃描，因為會使用表鎖 盡可能緩存所有的索引和數(shù)據(jù)，提高響應(yīng)速度 在大批量小插入的時候，盡量自己控制事務(wù)而不要使用autocommit自動提交 合理設(shè)置innodb_flush_log_at_trx_commit參數(shù)值，不要過度追求安全性 避免主鍵更新，因為這會帶來大量的數(shù)據(jù)移動

其它細節(jié)

?InnoDB 中不保存表的具體行數(shù)，注意的是，當(dāng)count(*)語句包含 where條件時，兩種表的操作是一樣的?對于AUTO_INCREMENT類型的字段，InnoDB中必須包含只有該字段的索引，但是在MyISAM表中，可以和其他字段一起建立聯(lián)合索引， 如果你為一個表指定AUTO_INCREMENT列，在數(shù)據(jù)詞典里的InnoDB表句柄包含一個名為自動增長計數(shù)器的計數(shù)器，它被用在為該列賦新值。自動增長計數(shù)器僅被存儲在主內(nèi)存中，而不是存在磁盤?DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除?LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，導(dǎo)入數(shù)據(jù)后再改成InnoDB表，但是對于使用的額外的InnoDB特性(例如外鍵)的表不適用?如果執(zhí)行大量的SELECT，MyISAM是更好的選擇，如果你的數(shù)據(jù)執(zhí)行大量的INSERT或UPDATE，出于性能方面的考慮，應(yīng)該使用InnoDB表

為什么MyISAM會比Innodb 的查詢速度快

InnoDB 在做SELECT的時候，要維護的東西比MYISAM引擎多很多；

1.InnoDB 要緩存數(shù)據(jù)和索引，MyISAM只緩存索引塊，這中間還有換進換出的減少2.innodb尋址要映射到塊，再到行，MyISAM記錄的直接是文件的OFFSET，定位比INNODB要快3.InnoDB 還需要維護MVCC一致；雖然你的場景沒有，但他還是需要去檢查和維護

MVCC ( Multi-Version Concurrency Control )多版本并發(fā)控制

InnoDB ：通過為每一行記錄添加兩個額外的隱藏的值來實現(xiàn)MVCC，這兩個值一個記錄這行數(shù)據(jù)何時被創(chuàng)建，另外一個記錄這行數(shù)據(jù)何時過期(或者被刪除)。但是InnoDB并不存儲這些事件發(fā)生時的實際時間，相反它只存儲這些事件發(fā)生時的系統(tǒng)版本號。這是一個隨著事務(wù)的創(chuàng)建而不斷增長的數(shù)字。每個事務(wù)在事務(wù)開始時會記錄它自己的系統(tǒng)版本號。每個查詢必須去檢查每行數(shù)據(jù)的版本號與事務(wù)的版本號是否相同。讓我們來看看當(dāng)隔離級別是REPEATABLE READ時這種策略是如何應(yīng)用到特定的操作的

SELECT InnoDB必須每行數(shù)據(jù)來保證它符合兩個條件

1.InnoDB必須找到一個行的版本，它至少要和事務(wù)的版本一樣老(也即它的版本號不大于事務(wù)的版本號)。這保證了不管是事務(wù)開始之前，或者事務(wù)創(chuàng)建時，或者修改了這行數(shù)據(jù)的時候，這行數(shù)據(jù)是存在的。2.這行數(shù)據(jù)的刪除版本必須是未定義的或者比事務(wù)版本要大。這可以保證在事務(wù)開始之前這行數(shù)據(jù)沒有被刪除。

mysql性能討論

MyISAM最為人垢病的缺點就是缺乏事務(wù)的支持

InnoDB 的磁盤性能很令人擔(dān)心

MySQL 缺乏良好的 tablespace

兩種類型最主要的差別就是Innodb 支持事務(wù)處理與外鍵和行級鎖.而MyISAM不支持.所以MyISAM往往就容易被人認為只適合在小項目中使用。

我作為使用MySQL的用戶角度出發(fā)，Innodb和MyISAM都是比較喜歡的，但是從我目前運維的數(shù)據(jù)庫平臺要達到需求：99.9%的穩(wěn)定性，方便的擴展性和高可用性來說的話，MyISAM絕對是我的首選。

原因如下：

1.首先我目前平臺上承載的大部分項目是讀多寫少的項目，而MyISAM的讀性能是比Innodb強不少的。2.MyISAM的索引和數(shù)據(jù)是分開的，并且索引是有壓縮的，內(nèi)存使用率就對應(yīng)提高了不少。能加載更多索引，而Innodb是索引和數(shù)據(jù)是緊密捆綁的，沒有使用壓縮從而會造成Innodb比MyISAM體積龐大不小。3.從平臺角度來說，經(jīng)常隔1，2個月就會發(fā)生應(yīng)用開發(fā)人員不小心update一個表where寫的范圍不對，導(dǎo)致這個表沒法正常用了，這個時候MyISAM的優(yōu)越性就體現(xiàn)出來了，隨便從當(dāng)天拷貝的壓縮包取出對應(yīng)表的文件，隨便放到一個數(shù)據(jù)庫目錄下，然后dump成sql再導(dǎo)回到主庫，并把對應(yīng)的binlog補上。如果是Innodb，恐怕不可能有這么快速度，別和我說讓Innodb定期用導(dǎo)出xxx.sql機制備份，因為我平臺上最小的一個數(shù)據(jù)庫實例的數(shù)據(jù)量基本都是幾十G大小。4.從我接觸的應(yīng)用邏輯來說，select count(*) 和order by 是最頻繁的，大概能占了整個sql總語句的60%以上的操作，而這種操作Innodb其實也是會鎖表的，很多人以為Innodb是行級鎖，那個只是where對它主鍵是有效，非主鍵的都會鎖全表的。5.還有就是經(jīng)常有很多應(yīng)用部門需要我給他們定期某些表的數(shù)據(jù)，MyISAM的話很方便，只要發(fā)給他們對應(yīng)那表的frm.MYD,MYI的文件，讓他們自己在對應(yīng)版本的數(shù)據(jù)庫啟動就行，而Innodb就需要導(dǎo)出xxx.sql了，因為光給別人文件，受字典數(shù)據(jù)文件的影響，對方是無法使用的。6.如果和MyISAM比insert寫操作的話，Innodb還達不到MyISAM的寫性能，如果是針對基于索引的update操作，雖然MyISAM可能會遜色Innodb,但是那么高并發(fā)的寫，從庫能否追的上也是一個問題，還不如通過多實例分庫分表架構(gòu)來解決。7.如果是用MyISAM的話，merge引擎可以大大加快應(yīng)用部門的開發(fā)速度，他們只要對這個merge表做一些select count(*)操作，非常適合大項目總量約幾億的rows某一類型(如日志，調(diào)查統(tǒng)計)的業(yè)務(wù)表。

當(dāng)然Innodb也不是絕對不用，用事務(wù)的項目如模擬炒股項目，我就是用Innodb的，活躍用戶20多萬時候，也是很輕松應(yīng)付了，因此我個人也是很喜歡Innodb的，只是如果從數(shù)據(jù)庫平臺應(yīng)用出發(fā)，我還是會首選MyISAM。

另外，可能有人會說你MyISAM無法抗太多寫操作，但是我可以通過架構(gòu)來彌補，說個我現(xiàn)有用的數(shù)據(jù)庫平臺容量：主從數(shù)據(jù)總量在幾百T以上，每天十多億 pv的動態(tài)頁面，還有幾個大項目是通過數(shù)據(jù)接口方式調(diào)用未算進pv總數(shù)，(其中包括一個大項目因為初期memcached沒部署,導(dǎo)致單臺數(shù)據(jù)庫每天處理 9千萬的查詢)。而我的整體數(shù)據(jù)庫服務(wù)器平均負載都在0.5-1左右。

MyISAM索引實現(xiàn)

MyISAM引擎使用B+Tree作為索引結(jié)構(gòu)，葉節(jié)點的data域存放的是數(shù)據(jù)記錄的地址。如圖：

這里設(shè)表一共有三列，假設(shè)我們以Col1為主鍵，則上圖是一個MyISAM表的主索引(Primary key)示意。可以看出MyISAM的索引文件僅僅保存數(shù)據(jù)記錄的地址。在MyISAM中，主索引和輔助索引(Secondary key)在結(jié)構(gòu)上沒有任何區(qū)別，只是主索引要求key是唯一的，而輔助索引的key可以重復(fù)。如果我們在Col2上建立一個輔助索引，則此索引的結(jié)構(gòu)如下圖所示：

同樣也是一顆B+Tree，data域保存數(shù)據(jù)記錄的地址。因此，MyISAM中索引檢索的算法為首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，則取出其data域的值，然后以data域的值為地址，讀取相應(yīng)數(shù)據(jù)記錄。MyISAM的索引方式也叫做“非聚集”的，之所以這么稱呼是為了與InnoDB的聚集索引區(qū)分。

InnoDB索引實現(xiàn)

雖然InnoDB也使用B+Tree作為索引結(jié)構(gòu)，但具體實現(xiàn)方式卻與MyISAM截然不同。

第一個重大區(qū)別是InnoDB的數(shù)據(jù)文件本身就是索引文件。從上文知道，MyISAM索引文件和數(shù)據(jù)文件是分離的，索引文件僅保存數(shù)據(jù)記錄的地址。而在InnoDB中，表數(shù)據(jù)文件本身就是按B+Tree組織的一個索引結(jié)構(gòu)，這棵樹的葉節(jié)點data域保存了完整的數(shù)據(jù)記錄。這個索引的key是數(shù)據(jù)表的主鍵，因此InnoDB表數(shù)據(jù)文件本身就是主索引。

上圖是InnoDB主索引(同時也是數(shù)據(jù)文件)的示意圖，可以看到葉節(jié)點包含了完整的數(shù)據(jù)記錄。這種索引叫做聚集索引。因為InnoDB的數(shù)據(jù)文件本身要按主鍵聚集，所以InnoDB要求表必須有主鍵(MyISAM可以沒有)，如果沒有顯式指定，則MySQL系統(tǒng)會自動選擇一個可以唯一標識數(shù)據(jù)記錄的列作為主鍵，如果不存在這種列，則MySQL自動為InnoDB表生成一個隱含字段作為主鍵，這個字段長度為6個字節(jié)，類型為長整形。

第二個與MyISAM索引的不同是InnoDB的輔助索引data域存儲相應(yīng)記錄主鍵的值而不是地址。換句話說，InnoDB的所有輔助索引都引用主鍵作為data域。例如，下圖為定義在Col3上的一個輔助索引：

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

總結(jié)

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

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

微服務(wù)架構(gòu)微信交流群

?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。