為什麼索引可以讓查詢變快？
概述
人類儲存資訊的發展歷程大致經歷如下：
圖片
由於是個人憑著自己理解總結的，因此可能不一定精確，但是毋庸置疑的是，在當代，各大公司機構部門的資料都是維護在資料庫當中的。
資料庫作為資料儲存介質發展的最新產物，必然是具有許多優點的，其中一個很大的優點就是儲存在資料庫中的資料訪問速度非常快。
資料庫訪問速度快的一個很重要的原因就在於索引index的作用。也就是這篇文章的主要想介紹的內容，為什麼索引可以讓資料庫查詢變快？
計算機儲存原理
在理解索引這個概念之前，我們需要先了解一下計算機儲存方面的基本知識。
我們知道資料持久化之後存在了資料庫裡,那麼我現在的問題是資料庫將資料存在了哪裡？答案顯然是存在了計算機的儲存裝置上。就個人電腦而言，資料被存在了我們的電腦儲存裝置上。
計算機的儲存裝置有很多種，其中速度越快的越貴，因此容量也往往越小例如我們的RAM隨機儲存器，也就是大家平時說的記憶體條，速度慢的就相對便宜例如我們的硬碟。而我們的資料往往都是被存在最慢的儲存裝置硬碟上的，因為存在當中的資料在斷電之後依然存在。
計算機的儲存介質有多種，例如硬碟，例如告訴快取，不同的儲存介質的資料讀取速度是不一樣的。例如，像RAM這樣的易失性儲存裝置的讀寫操作就非常快，訪問其中的資料幾乎沒有延遲性。
由於這個原因，計算機作業系統的設計是這樣的：資料永遠不會直接從硬碟等機械裝置中取出，而是首先從硬碟轉移到更快的儲存裝置，例如RAM，從RAM當中應用程式直接按需獲取資料。
計算機內部的機械硬碟是下面這樣的：
圖片
在一個典型的硬碟驅動器中可以有很多個碟片，“碟片”在外觀上非常類似於一個光碟（但具有很高的儲存容量）。碟片又被磁軌分條，同時一個碟片又可以分為扇區。
要獲取資料，“碟片”需要由主軸進行旋轉。大多數硬碟供應商都提到了主軸旋轉的速度，例如，7200轉/分和15000轉/分。磁碟中的資料總是以扇區的固定大小倍數表示。因此，如果要從硬碟訪問資料，需要執行以下步驟，這也是效能開銷的主要來源。
- 確定資料所在的正確磁軌，並將磁頭移動到該磁軌。即通常說的尋道。
- 讓“主軸”旋轉碟片，使正確的扇區位於“磁碟頭”下方。
- 從扇區開始到扇區結束獲取整個資料。
如果資料恰好分佈在連續扇區上，那麼它將提高獲取資料的效能。因為主軸和磁頭本身不需要移動/旋轉，也就沒有太多開銷，但是大多數時候這種開銷是存在的。
由於存在這種開銷，我們不能直接從硬盤獲取資料。RAM的儲存器高效能的背後的主要原因是它沒有像硬碟那樣的機械運動部件。但是儘管RAM的效能很高，但它當中的資料卻不會用作永久儲存，斷電之後就會消失，重新啟動之後就什麼都沒有了，這是我們需要硬碟來進行持久化的原因所在。資料庫中的資料毫無疑問就是存放在硬碟當中的，因此訪問資料庫中的資料不可避免的會經歷磁碟操作的開銷。
索引是如何工作的？
知道上述知識後，索引就更容易理解了。
舉個例子，想象一下，現在有一本500頁厚包含幾十萬字的字典，同時裡面的字是無序排列的，現在我需要你從中找出某幾個字出來同時不允許檢視目錄。毫無疑問，我們只能一頁一頁的翻，這是非人類能接受的工作，我們必然想的是先看目錄，找到相關的字或者偏旁，然後去對應的地方查詢文字，這樣效率就大大提高了。目錄事實上就是一種索引，其思想一脈相承。
資料庫的索引類似於書中的這個目錄。索引會幫助我們快速檢索資料庫，查詢不需要通過整個表來獲取資料，而是從索引中找到資料塊。以一張資料庫表為例：
圖片
上表是一張真實的資料庫表，其中每一行是一條記錄，每條記錄都有欄位。假設上面的資料庫是一個有10萬條記錄的大資料庫。現在，我們想從10萬條記錄中搜索一些內容，那麼挨著一個一個搜尋無疑將花費很長的時間，這個時候我們在資料結構與演算法裡學的二分查詢法就派上了用場。
二分查詢法
使用二分查詢法，需要將資料先排序，但是其查詢效率將大大提高。
例子如下:
假設我們在上面的資料庫中使用的是固定長度的記錄,固定塊記錄大小為205個位元組， 預設塊大小是1024位元組。則：
固定記錄大小=204位元組，塊大小=1024位元組
所以每個資料塊的記錄數=1024/204=5條記錄，10萬條記錄就是2萬個塊
不使用任何演算法，我們要查詢100000條記錄中的某一條，，在最壞的情況下我們需要遍歷一遍2萬block才能獲得全部100000條記錄。但如果進行二分查詢，則只需要進行20000的對數基數2，即14.287712次即可。這意味著我們只需對排序後的值進行14次搜尋，就可以使用二分查詢到您感興趣的唯一值。
圖片
上圖是對一串數字生成的二叉查詢樹。其時間複雜度為O(n)=O(log2N),即以2為底，n的對數。其中n為查詢目標群體的總資料量。
例如，假設N為8，則O(n) = O(2為底8的對數) = O(3).
遍歷方式，其時間複雜度為O(n)
在上述例子當中，n就是10000。使用索引的時間複雜度為O(2為底10000的對數) 大約等於 13. 和O(10000)之間差大概800倍。
索引為何使得查詢變快？
這個時候我們就能直接回答上述問題了，建立了索引的資料，就是通過事先排好序，從而在查詢時可以應用二分查詢來提高查詢效率。這也解釋了為什麼索引應當儘可能的建立在主鍵這樣的欄位上，因為主鍵必須是唯一的，根據這樣的欄位生成的二叉查詢樹的效率無疑是最高的。
為什麼索引不能建立的太多？
如果一個表中所有欄位的索引很大，也會導致效能下降。想象一下，如果一個索引和一個表一樣長，那麼它將再次成為一個需要檢查的開銷。這就好比字典的目錄非常詳細，但是其長度已經和所有的文字一樣長，這個時候目錄本身的效率就大大下降了。
索引有弊端嗎？
肯定是有的，索引可以提高查詢讀取效能，而它將降低QQ買號平臺地圖寫入效能。當有索引時，如果更改一條記錄，或者在資料庫中插入一條新的記錄，它將執行兩個寫入操作（一個操作是寫入記錄本身，另一個操作是將更新索引）。因此，在定義索引時，必須牢記以下幾點：
- 索引表中的每個欄位將降低寫入效能。
- 建議使用表中的唯一值為欄位編制索引。
- 在關係資料庫中充當外來鍵的欄位必須建立索引，因為它們有助於跨多個表進行復雜查詢。
- 索引還使用磁碟空間，因此在選擇要索引的欄位時要小心。
什麼是聚集索引
聚集索引clustered index也叫聚簇索引，它的定義是：聚集索引的表中資料行的物理順序與列值（一般是主鍵的那一列）的邏輯順序相同，一個表中只能擁有一個聚集索引。
例如:
圖片
結合上面的表格就很好理解了：資料行的物理順序與列值的順序相同，如果我們查詢id比較靠後的資料，那麼這行資料的地址在磁碟中的實體地址也會比較靠後。聚集索引儲存記錄是物理上連續存在，而非聚集索引是邏輯上的連續，物理儲存並不連續。
為什麼查詢更快呢？我們通過上面的分析知道了索引是通過二叉樹的資料結構來描述的，我們可以這麼理解聚簇索引：索引的葉節點就是資料節點。而非聚簇索引的葉節點仍然是索引節點，只不過有一個指標指向對應的資料塊。
主鍵一般會預設建立聚集索引。
在建立聚集索引之前，應先了解您的資料是如何被訪問的。可考慮將聚集索引用於：
包含大量非重複值的列。使用下列運算子返回一個範圍值的查詢：BETWEEN、>、>=、< 和 <=。被連續訪問的列。返回大型結果集的查詢。經常被使用聯接或 GROUP BY 子句的查詢訪問的列；一般來說，這些是外來鍵列。對 ORDER BY 或 GROUP BY 子句中指定的列進行索引，可以使 SQL Server 不必對資料進行排序，因為這些行已經排序。這樣可以提高查詢效能。OLTP型的應用程式，這些程式要求進行非常快速的單行查詢（一般通過主鍵）。應在主鍵上建立聚集索引。聚集索引不適用於：
頻繁更改的列 這將導致整行移動，因為 SQL Server 必須按物理順序保留行中的資料值。這一點要特別注意，因為在大資料量事務處理系統中資料是易失的
索引失效的典型例子
條件中用or，即使其中有條件帶索引，也不會使用索引查詢，這就是查詢儘量不要用or的原因，用in吧。
常見的sql優化手段有哪些
1.避免全表掃描
全表掃描往往發生在下面幾種情況:
- SQL的on子句或者where子句涉及到的列上沒有索引；
- 表資料量很小，走索引查詢比全表掃描更麻煩；這對於少於10行且行長度較短的表來說很常見
2.避免索引失效
不在索引列上做任何操作（計算，函式、自動or手動型別轉換），這樣會導致索引失效而轉向全表掃描。另外，關注公眾號Java技術棧，在後臺回覆：面試，可以獲取我整理的 MySQL 系列面試題和答案，非常齊全。
儲存引擎不能使用索引中範圍條件右邊的列。這個是因為age中查詢時範圍查詢了，pos列的索引就沒有生效了。
儘量使用覆蓋索引（只訪問索引的查詢（索引列和查詢列一致）），減少select *。
對於MySQL而言：
- mysql在使用不等於（!=或者<>）的時候無法使用索引會導致全表掃描
- is null,is not null也無法使用索引
- like 萬用字元開頭'%abc..'，mysql索引會失效會變成全表掃描的操作