一. 說說你對索引的認識（索引的結構、對dml影響、對查詢影響、為什麼提高查詢效能）
索引有b-tree、bit、cluster等型別。oracle使用了乙個複雜的自平衡b-tree結構;通常來說，在表上建立恰當的索引，查詢時會改進查詢效能。但在進行插入、刪除、修改時，同時會進行索引的修改，在效能上有一定的影響。有索引且查詢條件能使用索引時，資料庫會先度取索引，根據索引內容和查詢條件，查詢出rowid，再根據rowid取出需要的資料。由於索引內容通常比全表內容要少很多，因此通過先讀索引，能減少i/o，提高查詢效能。
二. 使用索引查詢一定能提高查詢的效能嗎?為什麼
通常,通過索引查詢資料比全表掃瞄要快.但是我們也必須注意到它的代價.
索引需要空間來儲存,也需要定期維護, 每當有記錄在表中增減或索引列被修改時,索引本身也會被修改. 這意味著每條記錄的insert,delete,update將為此多付出4,5 次的磁碟i/o. 因為索引需要額外的儲存空間和處理,那些不必要的索引反而會使查詢反應時間變慢.使用索引查詢不一定能提高查詢效能,索引範圍查詢(index range scan)適用於兩種情況:
基於乙個範圍的檢索,一般查詢返回結果集小於表中記錄數的30%宜採用;
基於非唯一性索引的檢索
索引就是為了提高查詢效能而存在的,如果在查詢中索引沒有提高效能,只能說是用錯了索引,或者講是場合不同。
關於b-tree結構：
b- 樹
是一種多路搜尋樹（並不是二叉的）：
1. 定義任意非葉子結點最多只有 m 個兒 子；且 m>2 ；
2. 根結點的兒子數為 [2, m] ；
3. 除根結點以外的非葉子結點的兒子數為 [m/2, m] ；
4. 每個結點存放至少 m/2-1 （取 上整）和至多 m-1 個關鍵字；（至少 2 個關鍵 字）
5. 非葉子結點的關鍵字個數 = 指向兒 子的指標個數 -1 ；
6. 非葉子結點的關鍵字： k[1], k[2], …, k[m-1] ；且 k[i] < k[i+1] ；
7. 非葉子結點的指標： p[1], p[2], …, p[m] ；其中 p[1] 指向關鍵字小於 k[1] 的子樹， p[m] 指向關鍵字大於 k[m-1] 的子樹，其它 p[i] 指 向關鍵字屬於 (k[i-1], k[i]) 的子樹；
8. 所有葉子結點位於同一層；
如：（ m=3 ）
b- 樹的搜尋，從根 結點開始，對結點內的關鍵字（有序）序列進行二分查詢，如果命中則結束，否則進入查詢關鍵字所屬範圍的兒子結點；重複，直到所對應的兒子指標為空，或已經 是葉子結點；
b- 樹的特性：
1. 關鍵字集合分布在整顆樹中；
2. 任何乙個關鍵字出現且只出現在乙個結點中；
3. 搜尋有可能在非葉子結點結束；
4. 其搜尋效能等價於在關鍵字全集內做一次二分查詢；
5. 自動層次控制；
由於限制了除根結點以外的非葉子結點，至少含有 m/2 個兒子，確保了結點的至少利用率，其最底搜尋效能為：
其中， m 為設定的非葉子結點最多子樹個 數， n 為關鍵字總數；
所以 b- 樹的效能總是等價於二分查詢 （與 m 值無關），也就沒有 b 樹平衡 的問題；
由於 m/2 的限制，在插入結點時，如果 結點已滿，需要將結點**為兩個各佔 m/2 的結點；刪除結點時，需將兩個不足 m/2 的 兄弟結點合併；
關於oracle索引
table access by index rowid index single value index range scan full scan fast full scan skip scan index join bitmap conversation 簡單的說索引分 單塊所掃和多塊索引掃。單...
關於ORACLE建立資料庫索引
由於公司電子商務 平台版本老化，且使用oracle資料庫，前期dba在設計資料庫建表結構時候存在一定的問題，對索引的使用不夠重視，大致資料的查詢比較慢 當然也有一些由於使用hibernate中不夠重視 color red oracle採用自下而上的順序解 析where子句,根據這個原理,表之間的連線...
Oracle索引 索引型別
oracle 提供了多種不同型別的索引以供使用。簡單地說，oracle 中包括如下索引 b 樹索引 這些是我所說的 傳統 索引。到目前為止，這是 oracle 和大多數其他資料庫中最常用的索引。b 樹的構造類似於二叉樹，能根據鍵提供一行或乙個行集的快速訪問，通常只需很少的讀操作就能找到正確的行。不過...