之前有關sql語句執行變慢的原因解析中，提到過索引在sql語句執行過程中的作用；用的好，可以提高10倍左右的速度，提高效率，而用的不好，會降低效率。通過三個方面解析索引
索引的使用場景
索引種類
聚集索引和非聚集索引的查詢效率
續--在資料結構中的索引原理
索引就好比⼀本書的⽬錄，它可以幫我們快速進⾏特定值的定位與查詢，從而加快資料查詢的效率。
(1)如果我們在進行資料庫查詢的時候，細心的觀察在執行幾十條資料查詢語句的執行時間，會發現，加和不加索引，區別不大，甚至，不加索引會比加索引要快。所以：
資料量不大的時候，盡量不要用索引
(2)乙個實驗資料如圖1
圖1
資料成一邊倒（某段值特別大，某段值特別小）的分布樣式時候，建立對應的索引，可以達到事半功倍的效果
因此，我們在使用索引的時候，不僅要看字段中的資料的個數，還要根據資料的分布狀況來考慮是否需要建立索引
普通索引：是最基礎的索引，沒有任何約束條件，主要提高查詢效率；
唯一索引：在普通索引的基礎上，增加了唯一性的約束，在一張表裡，可以有多個唯一索引。
主鍵索引：在唯⼀索引的基礎上增加了不為空的約束，也就 是 not null+unique，⼀張表⾥最多只有⼀個主鍵索引
全文索引：用的不多
普通索引、唯一索引、主鍵索引的關係是對資料的約束性在逐漸提公升
聚集索引和非聚集索引是根據索引的物理實現方式所劃分，通常情況下，聚集索引成為一級索引（自己定義的名字），聚集索引是主鍵索引;非聚集索引成為輔助索引或二級索引；
一般來講，聚集索引可以按照主鍵來排序儲存資料，主鍵的排序方式決定資料行的排序方式，每個表只能有乙個聚集索引；
而非聚集索引，他進行索引的時候，先找對應的聚集索引，之後在通過聚集索引，尋找對應的行
（1）聚集索引與非聚集索引的區分
圖2和圖3解釋的是聚集索引和非聚集索引的查詢效率對比
圖2
圖三結論:
1.建立索引，可以提高查詢效率
2.聚集索引的效率比非聚集索引效率略高，查詢次數比較多，建議使用聚集索引
（2）非聚集索引的用處--聯合索引
之前提到過，聚集索引乙個表只能建立乙個；但非聚集索引可以建立多個，那麼建立多個非聚集索引之後，查詢效率跟什麼有關呢？這是下面**的問題
最左匹配原則：最左優先的方式進行索引匹配。
結論聯合索引的查詢效率與最左邊的索引字段有關
二叉樹基本原理，通過構建孩子的方式，減少磁碟i/o操作，進而減少索引檢索消耗的時間；對於資料結構來講，由於記憶體存在丟失的可能性，所以磁碟，作為對資料操作的主要資料儲存媒介，如果我們能讓索引 的資料結構儘量減少硬碟的 i/o 操作，所消耗的時間也就越小。
（就好比我們從 1，2，3，4，5，6，7 ，7個數中找4；在沒有二叉樹的情況下，我們要每次開啟磁碟中的資料，再判斷是不是4，不是，則讀取下乙個,知道找到4;而二叉樹的原理是通過大小關係，將7個資料，以節點為依據，分左右孩子，如果左孩子表示比節點小的數，右孩子表示比節點大的數，再進行查詢的時候，每次開啟節點即可，從而大大減少了磁碟的i/o）
磁碟i/o是指磁碟的input/output--磁碟的輸入和輸出；（1）二叉樹中通過二分查詢法來查詢資料，可以將時間複雜度控制在o(log2n)上，從而大大減少檢索時間。那是因為：如果檢索的值是key
但是，當乙個二叉樹只有一邊節點的時候，它的時間複雜度就與二叉樹的深度成正相關，查詢時間也增加，時間複雜度變成o(n);
（2）為了解決二分查詢法**現一邊樹存在一邊倒的問題，出現了平衡二叉樹；每個節點都有2個子樹，且左右子樹的深度差不超過1；但如果資料太多，則平衡二叉樹的深度也變多；
（3）為了解決平衡二叉樹的深度問題，出現b樹，全稱叫balance樹，允許每個節點有》2的子節點，節點由關鍵字和子節點的指標組成；m成為最多子節點的個數的稱呼，叫做階。特點如下：
b樹的優點
b 樹相比於平衡⼆叉樹來說磁碟 i/o 操作要少
在資料查詢中比平衡⼆叉樹 效率要高
之所以會少的原因在於，b樹的對比在記憶體中進行，而平衡樹的對比在磁碟中進行；
（4）b+樹
b+樹是對b樹的改進；現在最主流dbms(database management system)中都支援b+樹的索引方式；
4.1 b+樹與b樹的差異
4.2 b+樹的優點
作業一直執行
背景 乙個作業有7個步驟，前面的步驟成功 失敗都轉到下一步，直至最後退出，作業計畫是每天早上8點執行。步驟中的語句是例行檢查指令碼，之前的歷史記錄都是一分鐘內完成。此次重啟資料庫伺服器後，檢查發現此作業在重啟受影響範圍內。檢視作業歷史記錄，顯示作業正在進行，持續時間為3天8小時43分鐘，而且持續時間...
SQL索引重建
前2周出現一件怪異的事情。乙個新版本下發到生產環境之後，某個崗位的某個頁面展示異常的慢，展示達到了20秒，提交一筆頁面則達到了10秒.問題都是這樣，當你過後覺得十分十分十分的簡單，但是當時對你來說簡直是暈頭轉向，一方面是行方不斷追問，另一方面是業務人員 都要打爆的質疑。在這樣環境下你需要的是冷靜的思...
補償介面中迴圈一直執行sql的問題
事件 專案即將上線，測試，觀察日誌，發現一sql在dal.xml中一直刷日誌，但對應在biz日誌卻是空的 排查步驟 1 檢視對應日誌的sql，在專案中找到對應 所在位置，檢視入口與 邏輯 介面是用作補償，使用的是簡答的controller呼叫業務，排程配置在任務系統，該sql是在補償中輪詢修改查詢符...