索引的基本概念
索引是一種特殊類型的數據庫對象，它與表有着密切的聯系。
索引是為檢索而存在的。如一些書籍的末尾就專門附有索引，指明了某個關鍵字在正文中的出現的頁碼位置，方便我們查找，但大多數的書籍只有目錄，目錄不是索引，只是書中內容的排序，並不提供真正的檢索功能。可見建立索引要單獨占用空間；索引也並不是必須要建立的，它們只是為更好、更快的檢索和定位關鍵字而存在。
再進一步說，我們要在圖書館中查閱圖書，該怎么辦呢？圖書館的前台有很多叫做索引卡片櫃的小櫃子，里面分了若干的類別供我們檢索圖書，比如你可以用書名的筆畫順序或者拼音順序作為查找的依據，你還可以從作者名的筆畫順序或拼音順序去查詢想要的圖書，反正有許多檢索方式，但有一點很明白，書庫中的書並沒有按照這些卡片櫃中的順序排列——雖然理論上可以這樣做，事實上，所有圖書的脊背上都人工的粘貼了一個特定的編號①，它們是以這個順序在排列。索引卡片中並沒有指明這本書擺放在書庫中的第幾個書架的第幾本，僅僅指明了這個特定的編號。管理員則根據這一編號將請求的圖書返回到讀者手中。這是很形象的例子。
索引分類：聚集索引和非聚集索引 （注意：聚集索引會改變記錄的物理位置）
從形式上而言，索引分為聚集索引（Clustered Indexes）和非聚集索引（NonClustered Indexes）。
聚集索引---相當於書籍脊背上那個特定的編號。如果對一張表建立了聚集索引，其索引頁中就包含着建立索引的列的值（下稱索引鍵值），那么表中的記錄將按照該索引鍵值進行排序。比如，我們如果在“姓名”這一字段上建立了聚集索引，則表中的記錄將按照姓名進行排列；如果建立了聚集索引的列是數值類型的，那么記錄將按照該鍵值的數值大小來進行排列。
非聚集索引----用於指定數據的邏輯順序，也就是說，表中的數據並沒有按照索引鍵值指定的順序排列，而仍然按照插入記錄時的順序存放。其索引頁中包含着索引鍵值和它所指向該行記錄在數據頁中的物理位置，叫做行定位符（RID：Row ID）。好似書后面的的索引表，索引表中的順序與實際的頁碼順序也是不一致的。而且一本書也許有多個索引。比如主題索引和作者索引。
索引優點和不足
索引缺點：1：建立索引，系統要占用大約為表的1.2倍的硬盤和內存空間來保存索引。2：更新數據的時候，系統必須要有額外的時間來同時對索引進行更新，以維持數據和索引的一致性——這就如同圖書館要有專門的位置來擺放索引櫃，並且每當庫存圖書發生變化時都需要有人將索引卡片重整以保持索引與庫存的一致。
索引優點：在海量數據的情況下，如果合理的建立了索引，則會大大加強SQLS執行查詢、對結果進行排序、分組的操作效率。
當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，降低了數據的維護速度
建立索引時一定要在“加快查詢速度”與“降低修改速度”之間做好平衡，有得必有失，此消則彼長。
例：
select * from student的時候，內部會進行一次對 表student全表掃描。
比如b列代表的是 學生姓名
select * from student where b='張三' 此時oracle內部會對 屬於student表名為b_index的索引進行掃描。
如果該表有上百萬的數據，則該查詢效果會十分明顯。
在執行完 create index b_index on student(b);(注釋：創建一個簡單的索引，名為 "b_index"，在student表的 b 列)
oracle 自動創建一張索引表 里面的字段有 索引列b和rowid；就好比是書的目錄，有章節和頁碼一樣。這也就是為什么索引可以提高查詢速度的原因了。
說白了 索引只是用於優化where后面的條件查詢，但注意的是 不是索引越多越好，where后面使用到的索引列套用了函數的話 是不會只用到索引的，創建索引的列也不是那么隨便的。
ROWID是表中行的唯一標識，是一個偽列.
“索引表會根據索引列的值進行排序” 這個不一定。如果你批量插入數據，B列有10,20,30,40,50,60,70 可能現在的索引表中的索引列是按照順序的，但之后你又插入了個12，那么這行數據插入到表中后，也會插入到索引列的“最后”，這里的最后為什么用引號引起來，因為這個問題就會涉及到數據塊存儲方面的了。
其實最簡單 最形象的 就是書的目錄頁碼就是rowid 可能你的目錄是
索引列.................. rowid
第一章..................12
第二章..................8
第三章..................5
第四章..................3