· 先存儲數據低字節並不嚴重地影響速度;數據行中的字節通常是未聯合的,從一個方向讀未聯合的字節並不比從反向讀更佔用更多的資源。服務器上的獲取列值的代碼與其它代碼相比並不顯得時間緊。 html
· 大文件(達63位文件長度)在支持大文件的文件系統和操做系統上被支持。 mysql
· 當把刪除和更新及插入混合的時候,動態尺寸的行更少碎片。這要經過合併相鄰被刪除的塊,以及若下一個塊被刪除,就擴展到下一塊來自動完成。sql
· 每一個MyISAM表最大索引數是64。 這能夠經過從新編譯來改變。每一個索引最大的列數是16個。 數據庫
· 最大的鍵長度是1000字節。這也能夠經過編譯來改變。對於鍵長度超過250字節的狀況,一個超過1024字節的的鍵塊被用上。 緩存
· BLOB和TEXT列能夠被索引。安全
· NULL值被容許在索引的列中。這個佔每一個鍵的0-1個字節。 服務器
· 全部數字鍵值以高字節爲先被存儲以容許一個更高地索引壓縮。 併發
· 當記錄以排好序的順序插入(就像你使用一個AUTO_INCREMENT列之時),索引樹被劈開以便高節點僅包含一個鍵。這改善了索引樹的空間利用率。 性能
· 每表一個AUTO_INCREMEN列的內部處理。MyISAM爲INSERT和UPDATE操做自動更新這一 列。這使得AUTO_INCREMENT列更快(至少10%)。在序列頂的值被刪除以後就不能再利用。(當AUTO_INCREMENT列被定義爲多列索 引的最後一列,能夠出現重使用從序列頂部刪除的值的狀況 )。AUTO_INCREMENT值可用ALTER TABLE或myisamch來重置。測試
· 若是數據文件中間的表沒有自由塊了,在其它線程從表讀的同時,你能夠INSERT新行到表中。(這被認識爲併發操做 )。自由塊的出現是做爲刪除行的結果,或者是用比當前內容多的數據對動態長度行更新的結果。當全部自由塊被用完(填滿),將來的插入又變成併發。
· 你能夠把數據文件和索引文件放在不一樣目錄,用DATA DIRECTORY和INDEX DIRECTORY選項CREATE TABLE以得到更高的速度,請參閱13.1.5節,「CREATE TABLE語法」。
· 每一個字符列能夠又不一樣的字符集。
· 在MyISAM索引文件裏又一個標誌,它代表表是否被正確關閉。若是用--myisam-recover選項啓動mysqld,MyISAM表在打開得時候被自動檢查,若是被表被不恰當地關閉,就修復表。
· 若是你用--update-state選項運行myisamchk,它標註表爲已檢查。myisamchk --fast只檢查那些沒有這個標誌的表。
· myisamchk --analyze爲部分鍵存儲統計信息,也爲整個鍵存儲統計信息。
· myisampack能夠打包BLOB和VARCHAR列。
MyISAM也支持下列特徵:
· 支持true VARCHAR類型;VARCHAR列以存儲在2個字節中的長度來開始。
· 有VARCHAR的表能夠有固定或動態記錄長度。
· VARCHAR和CHAR列能夠多達64KB。
· 一個被搞亂的已計算索引對可對UNIQUE來使用。這容許你在表內任何列的合併上有UNIQUE。(儘管如此,你不能在一個UNIQUE已計算索引上搜索)。
InnoDB是爲處理巨大數據量時的最大性能設計。它的CPU效率多是任何其它基於磁盤的關係數據庫引擎所不能匹敵的。
InnoDB存儲引擎被徹底與MySQL服務器整合,InnoDB存儲引擎爲在主內存中緩存數據和索引而維持它本身的緩衝池。 InnoDB存儲它的表&索引在一個表空間中,表空間能夠包含數個文件(或原始磁盤分區)。這與MyISAM表不一樣,好比在MyISAM表中每一個表被存在 分離的文件中。InnoDB 表能夠是任何尺寸,即便在文件尺寸被限制爲2GB的操做系統上。
InnoDB默認地被包含在MySQL二進制分發中。Windows Essentials installer使InnoDB成爲Windows上MySQL的 默認表。
InnoDB被用來在衆多須要高性能的大型數據庫站點上產生。著名的Internet新聞站點Slashdot.org運行在 InnoDB上。Mytrix, Inc.在InnoDB上存儲超過1TB的數據,還有一些其它站點在InnoDB上處理平均每秒800次插入/更新的負荷。MyISAM 是MySQL中默認的存儲引擎,通常來講不是有太多人關心這個東西。決定使用什麼樣的存儲引擎是一個很tricky的事情,可是仍是值咱們去研究一下,這裏的文章只考慮 MyISAM 和InnoDB這兩個,由於這兩個是最多見的。
下面先讓咱們回答一些問題:
思考上面這些問題可讓你找到合適的方向,但那並非絕對的。若是你須要事務處理或是外鍵,那麼InnoDB 多是比較好的方式。若是你須要全文索引,那麼一般來講 MyISAM是好的選擇,由於這是系統內建的,然而,咱們其實並不會常常地去測試兩百萬行記錄。因此,就算是慢一點,咱們能夠經過使用Sphinx從 InnoDB中得到全文索引。
數據的大小,是一個影響你選擇什麼樣存儲引擎的重要因素,大尺寸的數據集趨向於選擇InnoDB方式,由於其支持事務處理和故障恢復。數據庫的在小 決定了故障恢復的時間長短,InnoDB能夠利用事務日誌進行數據恢復,這會比較快。而MyISAM可能會須要幾個小時甚至幾天來幹這些事,InnoDB 只須要幾分鐘。
您操做數據庫表的習慣可能也會是一個對性能影響很大的因素。好比: COUNT() 在 MyISAM 表中會很是快,而在InnoDB 表下可能會很痛苦。而主鍵查詢則在InnoDB下會至關至關的快,但須要當心的是若是咱們的主鍵太長了也會致使性能問題。大批的inserts 語句在MyISAM下會快一些,可是updates 在InnoDB 下會更快一些——尤爲在併發量大的時候。
因此,到底你檢使用哪個呢?根據經驗來看,若是是一些小型的應用或項目,那麼MyISAM 也許會更適合。固然,在大型的環境下使用MyISAM 也會有很大成功的時候,但卻不老是這樣的。若是你正在計劃使用一個超大數據量的項目,並且須要事務處理或外鍵支持,那麼你真的應該直接使用InnoDB方 式。但須要記住InnoDB 的表須要更多的內存和存儲,轉換100GB 的MyISAM 表到InnoDB 表可能會讓你有很是壞的體驗。
1.InnoDB不支持FULLTEXT類型的索引。
2.InnoDB 中不保存表的具體行數,也就是說,執行select count(*) from table時,InnoDB要掃描一遍整個表來計算有多少行,可是MyISAM只要簡單的讀出保存好的行數便可。注意的是,當count(*)語句包含 where條件時,兩種表的操做是同樣的。
3.對於AUTO_INCREMENT類型的字段,InnoDB中必須包含只有該字段的索引,可是在MyISAM表中,能夠和其餘字段一塊兒創建聯合索引。
4.DELETE FROM table時,InnoDB不會從新創建表,而是一行一行的刪除。
5.LOAD TABLE FROM MASTER操做對InnoDB是不起做用的,解決方法是首先把InnoDB表改爲MyISAM表,導入數據後再改爲InnoDB表,可是對於使用的額外的InnoDB特性(例如外鍵)的表不適用。
另外,InnoDB表的行鎖也不是絕對的,若是在執行一個SQL語句時MySQL不能肯定要掃描的範圍,InnoDB表一樣會鎖全表,例如update table set num=1 where name like 「%aaa%」