寫資料庫，我第一時間就想到了mysql、oracle、索引、儲存過程、查詢優化等等。
不知道大家是不是跟我想得一樣，我最想寫的是索引，為啥呢？
面試官：資料庫有幾千萬的資料，查詢又很慢我們怎麼辦？
面試者：加索引。
面試官：那索引有哪些資料型別？索引是怎麼樣的一種結構？哪些欄位又適合索引呢？b+的優點？聚合索引和非聚合索引的區別？為什麼說索引會降低插入、刪除、修改等維護任務的速度？……..
hash，btree
首先雜湊表可能出現雜湊衝突。
那麼對於這樣乙個索引結構，現在來執行下面的sql語句：
select * from sanguo where name = '雞蛋'select * from sanguo where name > '雞蛋'有序陣列，它在等值查詢以及範圍查詢的時候都很好
有序的適合靜態陣列，因為如果我們增刪改資料的時候就會改變他的結構，比如新增，那在你新增的位置後面，所有的節點都會後移，成本很高
可以用來做靜態儲存引擎，用來儲存靜態資料，例如2023年支付寶賬單等，不會變動的歷史資料
二叉樹是有序的，所以支援範圍查詢，但是他的時間複雜度是o(log(n))，為了維持這個時間複雜度，更新的時間複雜度也得是o(log(n))，那就得保持這棵樹是完全平衡的二叉樹了。另外二叉樹的資料多了之後，樹會變的很高，查詢的成本就會隨著樹高的增加而增加。
同樣的元素，b樹的表示要比完全平衡二叉樹要矮，原因在於b樹中的乙個節點可以儲存多個元素。b樹其實就已經是乙個不錯的資料結構了，用來做索引效果還是不錯的。
同樣的元素，b+樹的要比b樹胖，原因在於b+樹中的非葉子節點會冗餘乙份在葉子節點中，並且葉子節點之間用指標相連。
而b+樹是b樹的公升級版，只是把非葉子節點冗餘一下，這麼做的好處是為了提高範圍查詢的效率。
提高了的原因也無非是會有指標指向下乙個節點的葉子節點。並且b+樹里的元素也是有序的。
b+樹中乙個節點為一頁或者頁的倍數最為合適
因為如果乙個節點的大小小於1頁，那麼讀取這個節點的時候其實也會讀出1頁，造成資源的浪費。
如果乙個節點的大小大於1頁，比如1.2頁，那麼讀取這個節點的時候會讀出2頁，也會造成資源的浪費。
所以為了不造成浪費，所以最後把乙個節點的大小控制在1頁、2頁、3頁、4頁等倍數頁大小最為合適。
首先mysql的基本儲存結構就是頁：
回表大概就是我們有個主鍵為id的索引，和乙個普通name欄位的索引，我們在普通欄位上搜尋：
select * from table where name = '丙丙'回到主鍵索引樹搜尋的過程，就是回表。不過也有方法避免回表，那就是覆蓋索引。
這個其實比較好理解，剛才我們是 select * ，查詢所有的，我們如果只查詢id那，其實在name欄位的索引上就已經有了，那就不需要回表了。
覆蓋索引可以減少樹的搜尋次數，提公升效能，他也是我們在實際開發過程中經常用來優化查詢效率的手段。
很多聯合索引的建立，就是為了支援覆蓋索引，特定的業務能極大的提公升效率。
最左匹配原則：
mysql資料庫 索引（2）
mysql索引的五種型別 主鍵索引 唯一索引 普通索引和全文索引 組合索引。通過新增索引可以提高資料的讀取資料，提高專案的併發能力和抗壓能力。1.建立表的時候直接指定 例如 create table school id int notnull t name varchar 16 not null i...
資料庫調優 2 索引
一 建立索引技巧 應該選擇資料量大的表。應該選擇使用頻繁的字段上建立索引,如經常查詢的字段,排序的字段,用於where子句作為條件判斷的字段。經常用在連線的列。應該選擇重複值較小的字段上建立所以,例如使用者表 應該在使用者id上建立索引,而不是使用者的位址如省份或者性別。當修改效能遠遠大於檢索效能時...
資料庫 資料庫索引
索引是儲存引擎用於快速找到記錄的一種資料結構。索引以檔案的形式儲存在磁碟中。索引可以包含乙個或多個列的值。儲存引擎查詢資料的時候，先在索引中找對應值，然後根據匹配的索引記錄找到對應的資料行。1.b tree索引 2.雜湊索引 myisam和innodb儲存引擎 只支援btree索引，也就是說預設使用...