筆者認為對於數據庫索引的作用，應該分兩面看。除了肯定其對數據庫性能帶來的正面影響外，還需要認識到其可能帶來的負面影響。只有如此，數據庫管理員才能夠在正確的場合使用正確的索引。要知道有時候一個錯誤的索引可能引發死鎖，並導致數據庫性能的急劇下降或進程終止;而如果數據庫管理員能夠做出一個正確的判斷的話，那麼可以使那些本來要運行幾個小時甚至一天的進程在幾分鐘之內就能夠完成。所以這兩個差距是一個天上、一個地下。故筆者希望通過這篇文章能夠讓各位讀者了解索引在使用過程中的限制，了解索引並不是萬能的。
一、索引對數據庫性能的影響跟數據選擇性直接掛鉤。
當用戶從數據表中查詢數據時，Oracle數據庫提供了兩種查詢的方式。一是從表中讀取每一行，就是大家常說的全表掃描;二是通過ROWID一此讀取一行。當表中記錄比較多的時候，很明顯第二種方式能夠更快的定位記錄內容。而索引其實就是建立在這個查詢原理之上的。如現在某個表中有300多萬條記錄，而現在用戶可能只需要了解其中的10條記錄信息。此時如果使用索引標識讀取的塊，則可以執行比較少的I/O，數據庫系統會很快找到用戶所需要的內容。而如果沒有使用索引的話，則需要讀取表中所有的塊。
如果在這個表中加入了索引，那麼到底對數據庫的性能影響有多大呢?這個就不好說了，因為其跟很多因素相關。如跟數據選擇性直接相關。如果用戶的數據非常具有選擇性，則表中家功能只有很少的行匹配索引值，則Oracle將能夠快速查詢匹配所引值得ROWID的索引，並且可以快速查詢少量的相關表快。如還是上面這個表中，其如果存儲有某個市的所有常住人口信息，其中身份證號碼肯定是少不了的。如此時用戶想根據身份證號碼來查詢某個人的信息時，那麼數據庫能夠在很短的時間內給出響應。這主要是因為用戶提供的數據非常具有選擇性，基本上跟數據庫中的索引值是一一對應的。而如果用戶想通過出身年月信息來查詢信息的話，則其數據庫反映的速度就會比較慢了。
可見索引對數據庫性能的影響直接跟數據的選擇性掛鉤。這對於數據庫管理員設計索引時很有啟發性。如數據庫管理員在設計索引時，最好能夠選擇哪些具有唯一性的字段或者重復性比較少的字段。如此的話，索引對於數據庫性能來說才有比較大的價值。
二、索引效果跟數據庫中記錄的具體存儲位置相關。
還是上面這張表中，如果現在用戶想查找年齡超過100歲的老人，要對他們去進行慰問。假設現在符合這個條件的人只有10人。那麼此時索引對數據庫性能會有怎麼樣的影響呢?此時顯然數據非常具有選擇性，但是並不一定索引能夠起到很好的效果。這還要看其具體存儲的位置。如果這十條記錄在硬盤中存儲的物理位置比較近，如可能在同一個扇區之內，則此時索引對於數據庫性能的影響就會比較大，能夠在最短時間內找到符合條件的數據。但是如果相關的行在表中存儲的位置並不互相靠近，則這個索引的效果就會逐漸減少。因為如果匹配索引值的數據分散在硬盤上的多個酷愛時，則必須從表中選擇多個單獨的塊以滿足查詢。
數據庫管理員對於這一點要特別注意。因為此時如果數據庫管理員查用了索引的話，那麼很可能是畫蛇添足。筆者建議，當數據庫管理員發現數據分散在表的多個塊的時候，最好是不要使用索引，而是執行全表掃描。此時執行掃描反而會比執行索引的效率更高。因為在執行全表掃描的時候，Oracle數據庫系統會使用多塊讀取以加速掃描表。而如果采用索引的話，則其讀取數據時是單塊讀取的。而由於數據存儲在多個塊中，所以其讀取的速度反而會更慢。
由此可見，Oracle數據庫管理員在數據庫設計與日常維護中，也要想辦法能夠讓數據盡量存儲在臨近的位置。如盡量減少在同一個服務器中不要部署不同的應用服務，防止硬盤產生過多的磁盤碎片;如需要采用多塊硬盤的話，則最好通過表空間把類似的表放在同一個表空間中，從而讓相關的行在表zhognd存儲位置盡量靠近，以提高索引的使用效果。也就是說，數據庫管理員在使用索引的時候，為表中的字段建立了索引這只是其工作的第一步。在後續數據庫維護與調整的過程中，仍然要注意數據存儲位置對索引的影響。
