數據庫建立索引爲什麼會加快查詢速度
首先明白爲什麼索引會增加速度，DB在執行一條Sql語句的時候，默認的方式是根據搜索條件進行全表掃描，遇到匹配條件的就加入搜索結果集合。如果我們對某一字段增加索引，查詢時就會先去索引列表中一次定位到特定值的行數，大大減少遍歷匹配的行數，所以能明顯增加查詢的速度。
MySQL官方對於索引的定義爲：索引是幫助MySQL高效獲取數據的數據結構。即可以理解爲：索引是數據結構。
我們知道，數據庫查詢是數據庫最主要的功能之一，我們都希望查詢數據的速度儘可能的快，因此數據庫系統的設計者會從查詢算法的角度進行優化。最基本的查詢算法當然是順序查找，當然這種時間複雜度爲O(n)的算法在數據量很大時顯然是糟糕的，於是有了二分查找、二叉樹查找等。但是二分查找要求被檢索數據有序，而二叉樹查找只能應用於二叉查找樹，但是數據本身的組織結構不可能完全滿足各種數據結構。所以，在數據之外，數據庫系統還維護者滿足特定查找算法的數據結構，這些數據結構以某種方式引用數據，這樣就可以在這些數據結構上實現高級查找算法。這種數據結構，就是索引。
B-Tree和B+Tree
目前大部分數據庫系統及文件系統都採用B-Tree和B+Tree作爲索引結構。
索引
索引的目的：提高查詢效率
原理：通過不斷的縮小想要獲得數據的範圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是我們總是通過同一種查找方式來鎖定數據。
數據結構：B+樹
圖解B+樹與查找過程：
如上圖，是一顆b+樹，關於b+樹的定義可以參見B+樹，這裏只說一些重點，淺藍色的塊我們稱之爲一個磁盤塊，可以看到每個磁盤塊包含幾個數據項（深藍色所示）和指針（黃色所示），如磁盤塊1包含數據項17和35，包含指針P1、P2、P3，P1表示小於17的磁盤塊，P2表示在17和35之間的磁盤塊，P3表示大於35的磁盤塊。真實的數據存在於葉子節點即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非葉子節點只不存儲真實的數據，只存儲指引搜索方向的數據項，如17、35並不真實存在於數據表中。
b+樹的查找過程
如圖所示，如果要查找數據項29，那麼首先會把磁盤塊1由磁盤加載到內存，此時發生一次IO，在內存中用二分查找確定29在17和35之間，鎖定磁盤塊1的P2指針，內存時間因爲非常短（相比磁盤的IO）可以忽略不計，通過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內存，發生第二次IO，29在26和30之間，鎖定磁盤塊3的P2指針，通過指針加載磁盤塊8到內存，發生第三次IO，同時內存中做二分查找找到29，結束查詢，總計三次IO。真實的情況是，3層的b+樹可以表示上百萬的數據，如果上百萬的數據查找只需要三次IO，性能提高將是巨大的，如果沒有索引，每個數據項都要發生一次IO，那麼總共需要百萬次的IO，顯然成本非常非常高。
b+樹性質
通過上面的分析，我們知道IO次數取決於b+數的高度h，假設當前數據表的數據爲N，每個磁盤塊的數據項的數量是m，則有h=㏒(m+1)N，當數據量N一定的情況下，m越大，h越小；而m = 磁盤塊的大小 / 數據項的大小，磁盤塊的大小也就是一個數據頁的大小，是固定的，如果數據項佔的空間越小，數據項的數量越多，樹的高度越低。這就是爲什麼每個數據項，即索引字段要儘量的小，比如int佔4字節，要比bigint8字節少一半。這也是爲什麼b+樹要求把真實的數據放到葉子節點而不是內層節點，一旦放到內層節點，磁盤塊的數據項會大幅度下降，導致樹增高。當數據項等於1時將會退化成線性表。
添加索引的話，首先去索引列表中查詢，而我們的索引列表是B類樹的數據結構，查詢的時間複雜度爲O(log2N)，定位到特定值得行就會非常快，所以其查詢速度就會非常快。
添加索引的話，首先去索引列表中查詢，而我們的索引列表是B類樹的數據結構，查詢的時間複雜度爲O(log2N)，定位到特定值得行就會非常快，所以其查詢速度就會非常快。
爲什麼說B+-tree比B 樹更適合實際應用中操作系統的文件索引和數據庫索引？
1) B+-tree的磁盤讀寫代價更低
B+-tree的內部結點並沒有指向關鍵字具體信息的指針。因此其內部結點相對B 樹更小。如果把所有同一內部結點的關鍵字存放在同一盤塊中，那麼盤塊所能容納的關鍵字數量也越多。一次性讀入內存中的需要查找的關鍵字也就越多。相對來說IO讀寫次數也就降低了。
舉個例子，假設磁盤中的一個盤塊容納16bytes，而一個關鍵字2bytes，一個關鍵字具體信息指針2bytes。一棵9階B-tree(一個結點最多8個關鍵字)的內部結點需要2個盤快。而B+ 樹內部結點只需要1個盤快。當需要把內部結點讀入內存中的時候，B 樹就比B+ 樹多一次盤塊查找時間(在磁盤中就是盤片旋轉的時間)。
2) B+-tree的查詢效率更加穩定
由於非終結點並不是最終指向文件內容的結點，而只是葉子結點中關鍵字的索引。所以任何關鍵字的查找必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數據的查詢效率相當。
讀者點評
fanyy1991（csdn用戶名）道：個人覺得這兩個原因都不是主要原因。數據庫索引採用B+樹的主要原因是 B樹在提高了磁盤IO性能的同時並沒有解決元素遍歷的效率低下的問題。正是爲了解決這個問題，B+樹應運而生。B+樹只要遍歷葉子節點就可以實現整棵樹的遍歷。而且在數據庫中基於範圍的查詢是非常頻繁的，而B樹不支持這樣的操作（或者說效率太低）。
上述那個問題轉載自：從B樹、B+樹、B*樹談到R 樹
那麼在任何時候都應該加索引麼？這裏有幾個反例：1、如果每次都需要取到所有表記錄，無論如何都必須進行全表掃描了，那麼是否加索引也沒有意義了。2、對非唯一的字段，例如“性別”這種大量重複值的字段，增加索引也沒有什麼意義。3、對於記錄比較少的表，增加索引不會帶來速度的優化反而浪費了存儲空間，因爲索引是需要存儲空間的，而且有個致命缺點是對於update/insert/delete的每次執行，字段的索引都必須重新計算更新。
那麼在什麼時候適合加上索引呢？我們看一個Mysql手冊中舉的例子，這裏有一條sql語句：
SELECT c.companyID, c.companyName FROM Companies c, User u WHERE c.companyID = u.fk_companyID AND c.numEmployees >= 0 AND c.companyName LIKE '%i%' AND u.groupID IN (SELECT g.groupID FROM Groups g WHERE g.groupLabel = 'Executive')
這條語句涉及3個表的聯接，並且包括了許多搜索條件比如大小比較，Like匹配等。在沒有索引的情況下Mysql需要執行的掃描行數是 77721876行。而我們通過在companyID和groupLabel兩個字段上加上索引之後，掃描的行數只需要134行。在Mysql中可以通過 Explain Select來查看掃描次數。可以看出來在這種聯表和複雜搜索條件的情況下，索引帶來的性能提升遠比它所佔據的磁盤空間要重要得多。
那麼索引是如何實現的呢？大多數DB廠商實現索引都是基於一種數據結構——B樹。oracle實現索引的數據結構是B*樹。具體關於B樹、B+樹、B*樹的講解可以查看另一篇博文：樹
可以看到在這棵B樹搜索英文字母複雜度只爲o(m)，在數據量比較大的情況下，這樣的結構可以大大增加查詢速度。然而有另外一種數據結構查詢的虛度比B樹更快——散列表。Hash表的定義是這樣的：設所有可能出現的關鍵字集合爲u，實際發生存儲的關鍵字記爲k，而|k|比|u|小很多。散列方法是通過散列函數h將u映射到表T[0,m-1]的下標上，這樣u中的關鍵字爲變量，以h爲函數運算結果即爲相應結點的存儲地址。從而達到可以在o(1)的時間內完成查找。
然而散列表有一個缺陷，那就是散列衝突，即兩個關鍵字通過散列函數計算出了相同的結果。設m和n分別表示散列表的長度和填滿的結點數，n/m爲散列表的填裝因子，因子越大，表示散列衝突的機會越大。
因爲有這樣的缺陷，所以數據庫不會使用散列表來做爲索引的默認實現，Mysql宣稱會根據執行查詢格式嘗試將基於磁盤的B樹索引轉變爲和合適的散列索引以追求進一步提高搜索速度。我想其它數據庫廠商也會有類似的策略，畢竟在數據庫戰場上，搜索速度和管理安全一樣是非常重要的競爭點。
基本概念介紹：
索引
使用索引可快速訪問數據庫表中的特定信息。索引是對數據庫表中一列或多列的值進行排序的一種結構，例如 employee 表的姓（lname）列。如果要按姓查找特定職員，與必須搜索表中的所有行相比，索引會幫助您更快地獲得該信息。
索引提供指向存儲在表的指定列中的數據值的指針，然後根據您指定的排序順序對這些指針排序。數據庫使用索引的方式與您使用書籍中的索引的方式很相似：它搜索索引以找到特定值，然後順指針找到包含該值的行。
在數據庫關係圖中，您可以在選定表的“索引/鍵”屬性頁中創建、編輯或刪除每個索引類型。當保存索引所附加到的表，或保存該表所在的關係圖時，索引將保存在數據庫中。有關詳細信息，請參見創建索引。
注意;並非所有的數據庫都以相同的方式使用索引。有關更多信息，請參見數據庫服務器注意事項，或者查閱數據庫文檔。
作爲通用規則，只有當經常查詢索引列中的數據時，才需要在表上創建索引。索引佔用磁盤空間，並且降低添加、刪除和更新行的速度。在多數情況下，索引用於數據檢索的速度優勢大大超過它的。
索引列
可以基於數據庫表中的單列或多列創建索引。多列索引使您可以區分其中一列可能有相同值的行。
如果經常同時搜索兩列或多列或按兩列或多列排序時，索引也很有幫助。例如，如果經常在同一查詢中爲姓和名兩列設置判據，那麼在這兩列上創建多列索引將很有意義。
確定索引的有效性：
檢查查詢的 WHERE 和 JOIN 子句。在任一子句中包括的每一列都是索引可以選擇的對象。
對新索引進行試驗以檢查它對運行查詢性能的影響。
考慮已在表上創建的索引數量。最好避免在單個表上有很多索引。
檢查已在表上創建的索引的定義。最好避免包含共享列的重疊索引。
檢查某列中唯一數據值的數量，並將該數量與表中的行數進行比較。比較的結果就是該列的可選擇性，這有助於確定該列是否適合建立索引，如果適合，確定索引的類型。
索引類型
根據數據庫的功能，可以在數據庫設計器中創建三種索引：唯一索引、主鍵索引和聚集索引。有關數據庫所支持的索引功能的詳細信息，請參見數據庫文檔。
提示：儘管唯一索引有助於定位信息，但爲獲得最佳性能結果，建議改用主鍵或唯一約束。
唯一索引
唯一索引是不允許其中任何兩行具有相同索引值的索引。
當現有數據中存在重複的鍵值時，大多數數據庫不允許將新創建的唯一索引與表一起保存。數據庫還可能防止添加將在表中創建重複鍵值的新數據。例如，如果在 employee 表中職員的姓 (lname) 上創建了唯一索引，則任何兩個員工都不能同姓。
主鍵索引
數據庫表經常有一列或列組合，其值唯一標識表中的每一行。該列稱爲表的主鍵。
在數據庫關係圖中爲表定義主鍵將自動創建主鍵索引，主鍵索引是唯一索引的特定類型。該索引要求主鍵中的每個值都唯一。當在查詢中使用主鍵索引時，它還允許對數據的快速訪問。
聚集索引
在聚集索引中，表中行的物理順序與鍵值的邏輯（索引）順序相同。一個表只能包含一個聚集索引。
如果某索引不是聚集索引，則表中行的物理順序與鍵值的邏輯順序不匹配。與非聚集索引相比，聚集索引通常提供更快的數據訪問速度。
建立方式和注意事項
最普通的情況，是爲出現在where子句的字段建一個索引。爲方便講述，我們先建立一個如下的表。
CREATE TABLE mytable (
id serial primary key,
category_id int not null default 0,
user_id int not null default 0,
adddate int not null default 0
);
如果你在查詢時常用類似以下的語句：
SELECT * FROM mytable WHERE category_id=1;
最直接的應對之道，是爲category_id建立一個簡單的索引：
CREATE INDEX mytable_categoryid
ON mytable (category_id);
OK.如果你有不止一個選擇條件呢？例如：
SELECT * FROM mytable WHERE category_id=1 AND user_id=2;
你的第一反應可能是，再給user_id建立一個索引。不好，這不是一個最佳的方法。你可以建立多重的索引。
CREATE INDEX mytable_categoryid_userid ON mytable (category_id,user_id);
注意到我在命名時的習慣了嗎？我使用”表名字段1名字段2名”的方式。你很快就會知道我爲什麼這樣做了。
現在你已經爲適當的字段建立了索引，不過，還是有點不放心吧，你可能會問，數據庫會真正用到這些索引嗎？測試一下就OK，對於大多數的數據庫來說，這是很容易的，只要使用EXPLAIN命令：
EXPLAIN
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2;
This is what Postgres 7.1 returns (exactly as I expected)
NOTICE: QUERY PLAN:
Index Scan using mytable_categoryid_userid on
mytable (cost=0.00..2.02 rows=1 width=16)
EXPLAIN
以上是postgres的數據，可以看到該數據庫在查詢的時候使用了一個索引（一個好開始），而且它使用的是我創建的第二個索引。看到我上面命名的好處了吧，你馬上知道它使用適當的索引了。
接着，來個稍微複雜一點的，如果有個ORDER BY字句呢？不管你信不信，大多數的數據庫在使用order by的時候，都將會從索引中受益。
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
很簡單，就象爲where字句中的字段建立一個索引一樣，也爲ORDER BY的字句中的字段建立一個索引：
CREATE INDEX mytable_categoryid_userid_adddate
ON mytable (category_id,user_id,adddate);
注意: “mytable_categoryid_userid_adddate” 將會被截短爲
“mytable_categoryid_userid_addda”
CREATE
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
NOTICE: QUERY PLAN:
Sort (cost=2.03..2.03 rows=1 width=16)
-> Index Scan using mytable_categoryid_userid_addda
on mytable (cost=0.00..2.02 rows=1 width=16)
EXPLAIN
看看EXPLAIN的輸出，數據庫多做了一個我們沒有要求的排序，這下知道性能如何受損了吧，看來我們對於數據庫的自身運作是有點過於樂觀了，那麼，給數據庫多一點提示吧。
爲了跳過排序這一步，我們並不需要其它另外的索引，只要將查詢語句稍微改一下。這裏用的是postgres，我們將給該數據庫一個額外的提示–在 ORDER BY語句中，加入where語句中的字段。這只是一個技術上的處理，並不是必須的，因爲實際上在另外兩個字段上，並不會有任何的排序操作，不過如果加入，postgres將會知道哪些是它應該做的。
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY category_id DESC,user_id DESC,adddate DESC;
NOTICE: QUERY PLAN:
Index Scan Backward using
mytable_categoryid_userid_addda on mytable
(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
現在使用我們料想的索引了，而且它還挺聰明，知道可以從索引後面開始讀，從而避免了任何的排序。
以上說得細了一點，不過如果你的數據庫非常巨大，並且每日的頁面請求達上百萬算，我想你會獲益良多的。不過，如果你要做更爲複雜的查詢呢，例如將多張表結合起來查詢，特別是where限制字句中的字段是來自不止一個表格時，應該怎樣處理呢？我通常都儘量避免這種做法，因爲這樣數據庫要將各個表中的東西都結合起來，然後再排除那些不合適的行，搞不好開銷會很大。
如果不能避免，你應該查看每張要結合起來的表，並且使用以上的策略來建立索引，然後再用EXPLAIN命令驗證一下是否使用了你料想中的索引。如果是的話，就OK。不是的話，你可能要建立臨時的表來將他們結合在一起，並且使用適當的索引。
要注意的是，建立太多的索引將會影響更新和插入的速度，因爲它需要同樣更新每個索引文件。對於一個經常需要更新和插入的表格，就沒有必要爲一個很少使用的where字句單獨建立索引了，對於比較小的表，排序的開銷不會很大，也沒有必要建立另外的索引。
以上介紹的只是一些十分基本的東西，其實裏面的學問也不少，單憑EXPLAIN我們是不能判定該方法是否就是最優化的，每個數據庫都有自己的一些優化器，雖然可能還不太完善，但是它們都會在查詢時對比過哪種方式較快，在某些情況下，建立索引的話也未必會快，例如索引放在一個不連續的存儲空間時，這會增加讀磁盤的負擔，因此，哪個是最優，應該通過實際的使用環境來檢驗。
在剛開始的時候，如果表不大，沒有必要作索引，我的意見是在需要的時候才作索引，也可用一些命令來優化表，例如MySQL可用”OPTIMIZE TABLE”。
綜上所述，在如何爲數據庫建立恰當的索引方面，你應該有一些基本的概念了。
轉載自：http://www.jb51.net/article/27315.htm
---------------------
作者：蹲茅坑逗蛆蛆
來源：CSDN
原文：https://blog.csdn.net/m0_38128121/article/details/79663261
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！