View Code
上述資料庫包含主鍵索引，但是沒有為主鍵命名，是以搜尋該索引的等級BLEVEL，可以通過以下查詢語句求出：
查詢結果如下圖所示：
從上述查詢結果中我們發現沒有BLEVEL和NUM_ROWS。
接下來我們查詢ID>700萬資料，之是以是700萬是因為我們總共資料時600多萬，這樣可以更加明顯的看出來有沒有索引的查詢效率。查詢語句如下：
查詢執行計劃如下：
從統計資訊中我們看出一共有“92 consistent gets”，相當于有92次IO。
然後我們删除上述主鍵SYS_COO38672，删除語句如下：
再次執行上述查詢語句，查詢執行計劃如下：
從統計資訊中我們看出一共有“45129 consistent gets”，相當于有45129次IO。
添加主鍵語句如下：
查詢該索引的等級BLEVEL，可以通過以下查詢語句求出：
從上述查詢結果中我們發現BLEVEL：2和NUM_ROWS=6428632，為表中記錄數。
發現是“ 3 consistent gets”，表明添加命名索引以後，隻需要3次IO就可以結束查詢。
上述的命名主鍵與非命名主鍵的說法是錯誤的，第二次consistent gets子是以很大是因為删除了主鍵索引，這是沒有錯的。而第三次的consistent gets為3，而第一次consistent gets為92，并不說明自定義命名的索引效率比系統命名的索引效率高。之是以第三次隻需要3次consistent gets是因為執行完第一次以後有緩存存在。假設在第一次查詢以後再一次查詢，那麼統計結果跟第三次一模一樣。
<a href="http://www.itpub.net/thread-1313899-1-1.html">http://www.itpub.net/thread-1313899-1-1.html</a>
查詢NO=5000，查詢語句如下：
第一次查詢得到的統計資訊：
第二次查詢得到的統計資訊：
第三次查詢得到的統計資訊：
第四次查詢得到的統計資訊：
第五次查詢得到的統計資訊：
第六次查詢得到的統計資訊：
第七次查詢得到的統計資訊：
從第一次到第三次查詢，都是無索引狀态下的查詢，我們可以發現：
第一次查詢時recursive calls=5>0，而後面兩次recursive calls都為0，這個也适用于後期有索引的情況
consistent gets在不斷縮小，知道最後不變。例如第一次查詢的consistent gets最大，而第二次和第三次的consistent gets相等。
在三次查詢過程中，physical reads都為0。（physical reads=0表明實體IO次數為0，也就是說沒有從硬碟上讀取資料到記憶體中。之是以physical reads=0，是因為前面insert的100000資料已經在buffer_cache裡了）
從第四次到第五次查詢，都是有索引狀态下的插叙，我們可以發現：
consistent gets次數在下降，consistent gets最後變到4。
recursive calls次數在下降，recursive calls最後變到0。
相對于第一次到第三次查詢，consistent gets明顯下降，這是因為添加了索引，前面第一次到第三次是全表掃描，而第四次跟第五次查詢是索引掃描。邏輯讀（consistent gets）之是以最後會是4，是是以需要讀取根節點一個，分支一個，葉子一個，表塊一個，共4個。
physical reads同上。
從六次到第七次查詢，是将原來索引換成了主鍵，我們可以發現：
consistent gets最後降為3，而不是4，這個是不明白的地方。
consistent gets同上
recursive calls同上
physical reads同上
主鍵也是索引的一種，隻要加了索引，那麼邏輯讀（consistent gets）就明顯降低，查詢效率大大提高。這也是索引的作用。
假設我們運作如下指令清空緩存：
然後再次執行查詢語句，得到的統計資訊如下：
可以看到physical reads=308。
再次執行查詢語句，，得到的統計資訊如下：
本文轉自xwdreamer部落格園部落格，原文連結：http://www.cnblogs.com/xwdreamer/archive/2012/06/11/2545689.html，如需轉載請自行聯系原作者