數據庫的結構（Tree）
B 樹：
是一種多路搜索樹
B 樹的搜索，從根結點開始，對結點內的關鍵字（有序）序列進行二分查找，如果
命中則結束，否則進入查詢關鍵字所屬範圍的兒子結點；重複，直到所對應的兒子指針爲空，或已經是葉子結點；
B 樹的特性：
1.關鍵字集合分佈在整顆樹中；
2.任何一個關鍵字出現且只出現在一個結點中；
3.搜索有可能在非葉子結點結束；
4.其搜索性能等價於在關鍵字全集內做一次二分查找；
5.自動層次控制；
B+樹
B+的搜索與B樹也基本相同，區別是B+樹只有達到葉子結點才命中（B-樹可以在
非葉子結點命中），其性能也等價於在關鍵字全集做一次二分查找；
B+的特性：
1.所有關鍵字都出現在葉子結點的鏈表中（稠密索引, 聚集索引），且鏈表中的關鍵字恰好
是有序的；
2.不可能在非葉子結點命中；
3.非葉子結點相當於是葉子結點的索引（稀疏索引，非聚集索引），葉子結點相當於是存儲（關鍵字）數據的數據層；
4.更適合文件索引系統；
紅黑樹
紅黑樹（Red-Black Tree）是二叉搜索樹（Binary Search Tree）的一種改進。我們知道二叉搜索樹在最壞的情況下可能會變成一個鏈表（當所有節點按從小到大的順序依次插入後）。而紅黑樹在每一次插入或刪除節點之後都會花O（log N）的時間來對樹的結構作修改，以保持樹的平衡。也就是說，紅黑樹的查找方法與二叉搜索樹完全一樣；插入和刪除節點的的方法前半部分節與二叉搜索樹完全一樣，而後半部分添加了一些修改樹的結構的操作。
紅黑樹的每個節點上的屬性除了有一個key、3個指針：parent、lchild、rchild以外，還多了一個屬性：color。它只能是兩種顏色：紅或黑。而紅黑樹除了具有二叉搜索樹的所有性質之外，還具有以下4點性質：
- 根節點是黑色的。
- 空節點是黑色的（紅黑樹中，根節點的parent以及所有葉節點lchild、rchild都不指向NULL，而是指向一個定義好的空節點）。
- 紅色節點的父、左子、右子節點都是黑色。
- 在任何一棵子樹中，每一條從根節點向下走到空節點的路徑上包含的黑色節點數量都相同。
小結
B樹：多路搜索樹，每個結點存儲M/2到M個關鍵字，非葉子結點存儲指向關鍵
字範圍的子結點；
所有關鍵字在整顆樹中出現，且只出現一次，非葉子結點可以命中；
B+樹：在B-樹基礎上，爲葉子結點增加鏈表指針，所有關鍵字都在葉子結點
中出現，非葉子結點作爲葉子結點的索引；B+樹總是到葉子結點才命中；
MySQL存儲引擎－－MyISAM與InnoDB區別
InnoDB和MyISAM是許多人在使用MySQL時最常用的兩個表類型，這兩個表類型各有優劣，視具體應用而定。基本的差別爲：MyISAM類型不支持事務處理等高級處理，而InnoDB類型支持。MyISAM類型的表強調的是性能，其執行數度比InnoDB類型更快，但是不提供事務支持，而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%”
**兩種類型最主要的差別就是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的。另外，可能有人會說你MyISAM無法抗太多寫操作，但是可以通過架構來彌補。
mysql的分庫分表