mysql 數據庫引擎

數據庫引擎介紹
MySQL數據庫引擎取決於MySQL在安裝的時候是如何被編譯的。要添加一個新的引擎，就必須從新編譯MYSQL。在缺省狀況下，MYSQL支持三個引擎：ISAM、MYISAM和HEAP。另外兩種類型INNODB和BERKLEY（BDB），也經常可使用。若是技術高超，還可使用MySQL+API本身作一個引擎。下面介紹幾種數據庫引擎：

ISAM：ISAM是一個定義明確且歷經時間考驗的數據表格管理方法，它在設計之時就考慮到 數據庫被查詢的次數要遠大於更新的次數。所以，ISAM執行讀取操做的速度很快，並且不佔用大量的內存和存儲資源。ISAM的兩個主要不足之處在於，它不 支持事務處理，也不可以容錯：若是你的硬盤崩潰了，那麼數據文件就沒法恢復了。若是你正在把ISAM用在關鍵任務應用程序裏，那就必須常常備份你全部的實 時數據，經過其複製特性，MYSQL可以支持這樣的備份應用程序。（isam 要常常備份數據）

MyISAM：MyISAM是MySQL的ISAM擴展格式和缺省的數據庫引擎。除了提供ISAM裏所沒有的索引和字段管理的大量功能，MyISAM還使用一種表格鎖定的機制，來優化多個併發的讀寫操做，其代價是你須要常常運行OPTIMIZE TABLE命令，來恢復被更新機制所浪費的空間。MyISAM還有一些有用的擴展，例如用來修復數據庫文件的MyISAMCHK工具和用來恢復浪費空間的 MyISAMPACK工具。MYISAM強調了快速讀取操做，這可能就是爲何MySQL受到了WEB開發如此青睞的主要緣由：在WEB開發中你所進行的大量數據操做都是讀取操做。因此，大多數虛擬主機提供商和INTERNET平臺提供商只容許使用MYISAM格式。MyISAM格式的一個重要缺陷就是不能在表損壞後恢復數據。

HEAP：HEAP容許只駐留在內存裏的臨時表格。駐留在內存裏讓HEAP要比ISAM和MYISAM都快，可是它所管理的數據是不穩定的，並且若是在關機以前沒有進行保存，那麼全部的數據都會丟失。在數據行被刪除的時候，HEAP也不會浪費大量的空間。HEAP表格在你須要使用SELECT表達式來選擇和操控數據的時候很是有用。要記住，在用完表格以後就刪除表格。

InnoDB：InnoDB數據庫引擎都是造就MySQL靈活性的技術的直接產品，這項技術就是MYSQL+API。在使用MYSQL的時候，你所面對的每個挑戰幾乎都源於ISAM和MyISAM數據庫引擎不支持事務處理（transaction process）也不支持外來鍵。儘管要比ISAM和 MyISAM引擎慢不少，可是InnoDB包括了對事務處理和外來鍵的支持，這兩點都是前兩個引擎所沒有的。如前所述，若是你的設計須要這些特性中的一者 或者二者，那你就要被迫使用後兩個引擎中的一個了。

若是感受本身的確技術高超，你還可以使用MySQL+API來建立本身的數據庫引擎。這個API爲你提供了操做字段、記錄、表格、數據庫、鏈接、安全賬號的功能，以及創建諸如MySQL這樣DBMS所須要的全部其餘無數功能。深刻講解API已經超出了本文的範圍，可是你須要瞭解MySQL+API的存在及其可交換引擎背後的技術，這一點是很重要的。估計這個插件式數據庫引擎的模型甚至可以被用來爲MySQL建立本地的XML提供器（XML provider）。（任何讀到本文的MySQL+API開發人員能夠把這一點看成是個要求。）
MyISAM與InnoDB的區別
　　InnoDB和MyISAM是許多人在使用MySQL時最經常使用的兩個表類型，這兩個表類型各有優劣，視具體應用而定。基本的差異爲：MyISAM類型不支持事務處理等高級處理，而InnoDB類型支持。MyISAM類型的表強調的是性能，其執行數度比InnoDB類型更快，可是不提供事務支持，而InnoDB提供事務支持已經外部鍵等高級數據庫功能。

如下是一些細節和具體實現的差異：
1.InnoDB不支持FULLTEXT類型的索引。
2.InnoDB 中不保存表的具體行數，也就是說，執行select count() fromtable時，InnoDB要掃描一遍整個表來計算有多少行，可是MyISAM只要簡單的讀出保存好的行數便可。注意的是，當count()語句包含where條件時，兩種表的操做是同樣的。
3.對於AUTO_INCREMENT類型的字段，InnoDB中必須包含只有該字段的索引，可是在MyISAM表中，能夠和其餘字段一塊兒創建聯合索引。
4.DELETE FROM table時，InnoDB不會從新創建表，而是一行一行的刪除。
5.LOAD TABLE FROMMASTER操做對InnoDB是不起做用的，解決方法是首先把InnoDB表改爲MyISAM表，導入數據後再改爲InnoDB表，可是對於使用的額外的InnoDB特性(例如外鍵)的表不適用。
另外，InnoDB表的行鎖也不是絕對的，假如在執行一個SQL語句時MySQL不能肯定要掃描的範圍，InnoDB表一樣會鎖全表，例如updatetable set num=1 where name like 「a%」
兩種類型最主要的差異就是Innodb支持事務處理與外鍵和行級鎖.而MyISAM不支持.因此MyISAM每每就容易被人認爲只適合在小項目中使用。
我做爲使用MySQL的用戶角度出發，Innodb和MyISAM都是比較喜歡的，可是從我目前運維的數據庫平臺要達到需求：99.9%的穩定性，方便的擴展性和高可用性來講的話，MyISAM絕對是個人首選。
緣由以下：
一、首先我目前平臺上承載的大部分項目是讀多寫少的項目，而MyISAM的讀性能是比Innodb強很多的。
二、MyISAM的索引和數據是分開的，而且索引是有壓縮的，內存使用率就對應提升了很多。能加載更多索引，而Innodb是索引和數據是緊密捆綁的，沒有使用壓縮從而會形成Innodb比MyISAM體積龐大不小。
三、從平臺角度來講，常常隔1，2個月就會發生應用開發人員不當心update一個表where寫的範圍不對，致使這個表無法正經常使用了，這個時候MyISAM的優越性就體現出來了，隨便從當天拷貝的壓縮包取出對應表的文件，隨便放到一個數據庫目錄下，而後dump成sql再導回到主庫，並把對應的binlog補上。若是是Innodb，恐怕不可能有這麼快速度，別和我說讓Innodb按期用導出xxx.sql機制備份，由於我平臺上最小的一個數據庫實例的數據量基本都是幾十G大小。
四、從我接觸的應用邏輯來講，select count(*) 和order by是最頻繁的，大概能佔了整個sql總語句的60%以上的操做，而這種操做Innodb其實也是會鎖表的，不少人覺得Innodb是行級鎖，那個只是where對它主鍵是有效，非主鍵的都會鎖全表的。
五、還有就是常常有不少應用部門須要我給他們按期某些表的數據，MyISAM的話很方便，只要發給他們對應那表的frm.MYD,MYI的文件，讓他們本身在對應版本的數據庫啓動就行，而Innodb就須要導出xxx.sql了，由於光給別人文件，受字典數據文件的影響，對方是沒法使用的。
六、若是和MyISAM比insert寫操做的話，Innodb還達不到MyISAM的寫性能，若是是針對基於索引的update操做，雖然MyISAM可能會遜色Innodb,可是那麼高併發的寫，從庫可否追的上也是一個問題，還不如經過多實例分庫分表架構來解決。
七、若是是用MyISAM的話，merge引擎能夠大大加快應用部門的開發速度，他們只要對這個merge表作一些selectcount(*)操做，很是適合大項目總量約幾億的rows某一類型(如日誌，調查統計)的業務表。
固然Innodb也不是絕對不用，用事務的項目如模擬炒股項目，我就是用Innodb的，活躍用戶20多萬時候，也是很輕鬆應付了，所以我我的也是很喜歡Innodb的，只是若是從數據庫平臺應用出發，我仍是會首MyISAM。
另外，可能有人會說你MyISAM沒法抗太多寫操做，可是我能夠經過架構來彌補，說個我現有用的數據庫平臺容量：主從數據總量在幾百T以上，天天十多億pv的動態頁面，還有幾個大項目是經過數據接口方式調用未算進pv總數，(其中包括一個大項目由於初期memcached沒部署,致使單臺數據庫天天處理9千萬的查詢)。而個人總體數據庫服務器平均負載都在0.5-1左右。
通常來講，MyISAM適合：
(1)作不少count 的計算；
(2)插入不頻繁，查詢很是頻繁；
(3)沒有事務。
InnoDB適合：
(1)可靠性要求比較高，或者要求事務；
(2)表更新和查詢都至關的頻繁，而且表鎖定的機會比較大的狀況指定數據引擎的建立
讓全部的靈活性成爲可能的開關是提供給ANSI SQL的MySQL擴展——TYPE參數。MySQL可以讓你在表格這一層指定數據庫引擎，因此它們有時候也指的是table formats。下面的示例代碼代表瞭如何建立分別使用MyISAM、ISAM和HEAP引擎的表格。要注意，建立每一個表格的代碼是相同的，除了最後的 TYPE參數，這一參數用來指定數據引擎。
如下爲引用的內容：
複製代碼代碼以下:

CREATE TABLE tblMyISAM (
id INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (id),
value_a TINYINT
) TYPE=MyISAM
CREATE TABLE tblISAM (
id INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (id),
value_a TINYINT
) TYPE=ISAM
CREATE TABLE tblHeap (
id INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (id),
value_a TINYINT
) TYPE=Heap

你也可使用ALTER TABLE命令，把原有的表格從一個引擎移動到另外一個引擎。下面的代碼顯示瞭如何使用ALTER TABLE把MyISAM表格移動到InnoDB的引擎：
如下爲引用的內容：
複製代碼代碼以下:

ALTER TABLE tblMyISAM CHANGE TYPE=InnoDB

MySQL用三步來實現這一目的。首先，這個表格的一個副本被建立。而後，任何輸入數據的改變都被排入隊列，同時這個副本被移動到另外一個引擎。最後，任何排入隊列的數據改變都被送交到新的表格裏，而原來的表格被刪除。
複製代碼代碼以下:

ALTER TABLE捷徑

若是隻是想把表格從ISAM更新爲MyISAM，你可使用MySQL_convert_table_format命令，而不須要編寫ALTER TABLE表達式。
你可使用SHOW TABLE命令（這是MySQL對ANSI標準的另外一個擴展）來肯定哪一個引擎在管理着特定的表格。SHOW TABLE會返回一個帶有多數據列的結果集，你能夠用這個結果集來查詢得到全部類型的信息：數據庫引擎的名稱在Type字段裏。下面的示例代碼說明了 SHOW TABLE的用法：
複製代碼代碼以下:

SHOW TABLE STATUS FROM tblInnoDB

你能夠用SHOW CREATE TABLE [TableName]來取回SHOW TABLE可以取回的信息。
通常狀況下，MySQL會默認提供多種存儲引擎，能夠經過下面的查看:
（1）看你的MySQL如今已提供什麼存儲引擎: mysql> show engines；
（2）看你的MySQL當前默認的存儲引擎: mysql> show variables like '%storage_engine%'；
（3）你要看某個表用了什麼引擎(在顯示結果裏參數engine後面的就表示該表當前用的存儲引擎): mysql> show create table 表名；
最後，若是你想使用沒有被編譯成MySQL也沒有被激活的引擎，那是沒有用的，MySQL不會提示這一點。而它只會給你提供一個缺省格式（MyISAM）的表格。除了使用缺省的表格格式外，還有辦法讓MySQL給出錯誤提示，可是就如今而言，若是不能確定特定的數據庫引擎是否可用的話，你要使用SHOW TABLE來檢查表格格式。
更多的選擇意味着更好的性能
用於特定表格的引擎都須要從新編譯和追蹤，考慮到這種的額外複雜性，爲何你仍是想要使用非缺省的數據庫引擎呢？答案很簡單：要調整數據庫來知足你的要求。
能夠確定的是，MyISAM的確快，可是若是你的邏輯設計須要事務處理，你就能夠自由使用支持事務處理的引擎。進一步講，因爲MySQL可以容許你在表格這一層應用數據庫引擎，因此你能夠只對須要事務處理的表格來進行性能優化，而把不須要事務處理的表格交給更加輕便的MyISAM引擎。對於 MySQL而言，靈活性纔是關鍵。
性能測試
全部的性能測試在：Micrisoft window xp sp2 ， Intel(R) Pentinum(R) M processor 1.6oGHz 1G 內存的電腦上測試。
測試方法：連續提交10個query， 表記錄總數：38萬 ， 時間單位 s
引擎類型MyISAMInnoDB 性能相差
count 0.00083573.01633609
查詢主鍵 0.005708 0.15742 7.57
查詢非主鍵 24.01 80.37 3.348
更新主鍵 0.008124 0.8183 100.7
更新非主鍵 0.004141 0.02625 6.338
插入 0.004188 0.3694 88.21
（1）加了索引之後，對於MyISAM查詢能夠加快：4 206.09733倍，對InnoDB查詢加快510.72921倍，同時對MyISAM更新速度減慢爲原來的1/2，InnoDB的更新速度減慢爲原來的1/30。要看狀況決定是否要加索引，好比不查詢的log表，不要作任何的索引。
（2）若是你的數據量是百萬級別的，而且沒有任何的事務處理，那麼用MyISAM是性能最好的選擇。
（3）InnoDB表的大小更加的大，用MyISAM可省不少的硬盤空間。
在咱們測試的這個38w的表中，表佔用空間的狀況以下：
引擎類型MyISAM InnoDB
數據 53,924 KB 58,976 KB
索引 13,640 KB 21,072 KB
佔用總空間 67,564 KB 80,048 KB
另一個176W萬記錄的表， 表佔用空間的狀況以下：
引擎類型MyIsam InnorDB
數據 56,166 KB 90,736 KB
索引 67,103 KB 88,848 KB
佔用總空間 123,269 KB 179,584 KB

其餘

MySQL 官方對InnoDB是這樣解釋的：InnoDB給MySQL提供了具備提交、回滾和崩潰恢復能力的事務安全（ACID兼容）存儲引擎。InnoDB鎖定在行級而且也在SELECT語句提供一個Oracle風格一致的非鎖定讀，這些特點增長了多用戶部署和性能。沒有在InnoDB中擴大鎖定的須要，由於在InnoDB中行級鎖定適合很是小的空間。InnoDB也支持FOREIGN KEY強制。在SQL查詢中，你能夠自由地將InnoDB類型的表與其它MySQL的表的類型混合起來，甚至在同一個查詢中也能夠混合。
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次插入/更新的.

一、Redis
Redis是一個很新的項目，剛剛發佈了1.0版本。Redis本質上是一個Key-Value類型的內存數據庫，很像memcached，整個數據庫統 統加載在內存當中進行操做，按期經過異步操做把數據庫數據flush到硬盤上進行保存。由於是純內存操做，Redis的性能很是出色，每秒能夠處理超過 10萬次讀寫操做，是我知道的性能最快的Key-Value DB。Redis的出色之處不只僅是性能，Redis最大的魅力是支持保存List鏈表和Set集合的數據結構，並且還支持對List進行各類操做，例如從 List兩端push和pop數據，取List區間，排序等等，對Set支持各類集合的並集交集操做，此外單個value的最大限制是1GB，不像 memcached只能保存1MB的數據，所以Redis能夠用來實現不少有用的功能，比方說用他的List來作FIFO雙向鏈表，實現一個輕量級的高性 能消息隊列服務，用他的Set能夠作高性能的tag系統等等。另外Redis也能夠對存入的Key-Value設置expire時間，所以也能夠被看成一 個功能增強版的memcached來用。Redis的主要缺點是數據庫容量受到物理內存的限制，不能用做海量數據的高性能讀寫，而且它沒有原生的可擴展機制，不具備scale（可擴展）能力，要 依賴客戶端來實現分佈式讀寫，所以Redis適合的場景主要侷限在較小數據量的高性能操做和運算上。目前使用Redis的網站有 github，Engine Yard。

一、MongoDB
MongoDB是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。他支持的數據結構很是鬆散，是相似 json的bjson格式，所以能夠存儲比較複雜的數據類型。Mongo最大的特色是他支持的查詢語言很是強大，其語法有點相似於面向對象的查詢語言，幾 乎能夠實現相似關係數據庫單表查詢的絕大部分功能，並且還支持對數據創建索引。Mongo主要解決的是海量數據的訪問效率問題，根據官方的文檔，當數據量達到50GB以上的時候，Mongo的數據庫訪問速度是MySQL的10倍以 上。Mongo的併發讀寫效率不是特別出色，根據官方提供的性能測試代表，大約每秒能夠處理0.5萬－1.5萬次讀寫請求。由於Mongo主要是支持海量數據存儲的，因此Mongo還自帶了一個出色的分佈式文件系統GridFS，能夠支持海量的數據存儲，但我也看到有些評論認 爲GridFS性能不佳，這一點仍是有待親自作點測試來驗證了。最後因爲Mongo能夠支持複雜的數據結構，並且帶有強大的數據查詢功能，所以很是受到歡迎，不少項目都考慮用MongoDB來替代MySQL來實現不是 特別複雜的Web應用，比方說why we migrated from MySQL to MongoDB就是一個真實的從MySQL遷移到MongoDB的案例，因爲數據量實在太大，因此遷移到了Mongo上面，數據查詢的速度獲得了很是顯著 的提高。MongoDB也有一個ruby的項目MongoMapper，是模仿Merb的DataMapper編寫的MongoDB的接口，使用起來很是簡單，幾 乎和DataMapper如出一轍，功能很是強大易用。

memcache

Memcache是一個高性能的分佈式的內存對象緩存系統，經過在內存裏維護一個統一的巨大的hash表，它可以用來存儲各類格式的數據，包括圖像、視頻、文件以及數據庫檢索的結果等。簡單的說就是將數據調用到內存中，而後從內存中讀取，從而大大提升讀取速度。
memcached是一種無阻塞的socket通訊方式服務，基於libevent庫，因爲無阻塞通訊，對內存讀寫速度很是之快。
　　memcached分服務器端和客戶端，能夠配置多個服務器端和客戶端，應用於分佈式的服務很是普遍。
　　memcached做爲小規模的數據分佈式平臺是十分有效果的。
memcached是鍵值一一對應，key默認最大不能超過128個字 節，value默認大小是1M，也就是一個slabs，若是要存2M的值（連續的），不能用兩個slabs，由於兩個slabs不是連續的，沒法在內存中 存儲，故須要修改slabs的大小，多個key和value進行存儲時，即便這個slabs沒有利用完，那麼也不會存放別的數據。

1.面向對象（繼承，多汰，封裝）優勢

一、易維護

　　採用面向對象思想設計的結構，可讀性高，因爲繼承的存在，即便改變需求，那麼維護也只是在局部模塊，因此維護起來是很是方便和較低成本的。
　　二、質量高
　　在設計時，可重用現有的，在之前的項目的領域中已被測試過的類使系統知足業務需求並具備較高的質量。
　　三、效率高
　　在軟件開發時，根據設計的須要對現實世界的事物進行抽象，產生類。使用這樣的方法解決問題，接近於平常生活和天然的思考方式，勢必提升軟件開發的效率和質量。
　　四、易擴展
　　因爲繼承、封裝、多態的特性，天然設計出高內聚、低耦合的系統結構，使得系統更靈活、更容易擴展，並且成本較低。

容錯當因爲某種緣由在系統中出現了數據，文件損壞或者丟失，系統能自動將這些數據回覆到發生以前