各位大大好， 一般初學者看到index，第一個概念就是書本最後幾頁的索引，書本的索引看起來跟資料庫的索引有類似的地方，而我看過資料庫原理的書，也是說資料庫的索引也是由兩個項目組成： 一．搜尋鍵（跟資料檔案主鍵的排序相同） 二．區段位址 正如書本的索引需要另外幾頁來安放，資料庫的索引也需要另外的空間來安放。書本索引是在整本書都完成後才建立的，如果此時書本內容有所更動的話，勢必連索引也要跟著修正。 資料庫的情形下，如果資料表已建立了索引，而此資料表並非唯讀，那麼當 資料有一筆新增或刪除時，索引定必重新排列。如果同一資料表同時有多人做新增或刪除時，每個新增或刪除的動作都必需對索引做重新排序。如果一分鐘 內有一千筆新增或刪除，索引就要每一分鐘進行一千次的重排，這樣的話索引豈不變成很大的負擔？ 這只以一個索引為例，如果資料表有四個索引，豈不變成每分鐘四千次的索引排序？

據我理解，資料庫並不是一有資料刪除，就把索引重做，而僅是用一個符號註記那筆資料刪除了（相同索引也是，另外，新增僅是新增一筆，單純的註記多一筆資料，在多一個索引註記位置），如此，資料庫才不用耗費大量資源在處理索引上。等到有空時可以人工的方式或者排成的方式，來壓縮資料庫重做索引，你看不管是MSSQL SERVER或MS ACCESS等資料庫不是有一個「壓縮資料庫」的選項嗎！那就是在處理不要的資料，重做索引，增加資料庫的存取效能！ -----------------------------------------------

引言: 各位大大好， 一般初學者看到index，第一個概念就是書本最後幾頁的索引，書本的索引看起來跟資料庫的索引有類似的地方，而我看過資料庫原理的書，也是說資料庫的索引也是由兩個項目組成： 一．搜尋鍵（跟資料檔案主鍵的排序相同） 二．區段位址 正如書本的索引需要另外幾頁來安放，資料庫的索引也需要另外的空間來安放。書本索引是在整本書都完成後才建立的，如果此時書本內容有所更動的話，勢必連索引也要跟著修正。 資料庫的情形下，如果資料表已建立了索引，而此資料表並非唯讀，那麼當 資料有一筆新增或刪除時，索引定必重新排列。如果同一資料表同時有多人做新增或刪除時，每個新增或刪除的動作都必需對索引做重新排序。如果一分鐘 內有一千筆新增或刪除，索引就要每一分鐘進行一千次的重排，這樣的話索引豈不變成很大的負擔？ 這只以一個索引為例，如果資料表有四個索引，豈不變成每分鐘四千次的索引排序？

1.按你的想法來架構理論基礎是可以說的通的, 索引動作的確會十分頻繁, 而事實是資料庫作業最頻繁的也是索引的維護, 因此索引越多不代表越好, 是會拖垮資料庫的異動模式, 所以早期資料庫最容易先毀損的就是INDEX檔了 2.至於索引如何進行運算, 這要視每一種資料庫的設計, 如早期的單機型資料庫dbf用B-TREE方式來建構索引, 發展至今SQL資料庫, 有自己的 DATA ENGINE來掌空, 索引在異動時是採用即時安插排列的, 可以假想索引就是圖書檔的書卡, 只要書目有異動那對那筆當時的情況直接做更新, 如果是有交易機制的資料庫會在APPLYUPDAE時才將異動結果回送, 索引的欄位一般都是一兩個欄位而已, 而且每個資料庫在處理多人存取時的索引會有其防護機制, 因此也不若我們想像每次都要重排那麼多次數, 如果我們不是要朝這方面研究發展的話, 對於索引我們只要掌握重點, 其他交給資料庫去處理就好了! 但是一個觀念, 檔案型的資料庫資料異動十分頻繁時, 索引檔的確會產生斷離現象而造成資料沒那麼多, 但索引檔不斷在"長大", 這時真的就要運作重整來將斷離的資料重新洗牌建立, 這個時候索引才會真正的重新按序排列並剔除無用的內容 3.另外, 你可能忽略了一點, 目前CPU的運算日新月異, 所以如你所說的狀況在電腦上運作其實只是一瞬間的事, 並不會如你所想的那麼恐怖, 如果你真考量資料庫如此龐大到足以影響索引維護(如上千萬筆), 你該考慮的是該採用大型資料庫系統, 而不是用一般資料庫來架構, 否則你想的情況是真的會發生的! 以上提供你參考 發表人 - P.D. 於 2005/05/29 11:08:41

謝謝兩位大大的回覆， 我想再請問一下，索引是如何增加搜尋效率？ 書本的索引，是採用 "挑選式 " 建立的。 不是書中所有字詞都列入索引頁當中，只有作者認為對讀者而言是重要的字詞，才會列入索引頁。這樣讀者只要在索引頁當中尋找關鍵字，即可找到該關鍵字在書中出現的位置。但是，如果關鍵字並沒有被書作者列入索引的話，讀者就一定要在整本書中尋找該關鍵字的出現位置。 問題來啦，我們在資料表中設定索引，是針對整個欄位來建立的，即針對欄位中所有的記錄，而不是"挑選"出欄位中部份的記錄來建立索引，這跟書本建立索引的方式並不相同。 因此，如果資料表是一個家族的成員資料，其中一個欄位是身份證號碼，另一欄位是姓名，身份證號碼肯定不會重複，但姓名也一定不會重複，因為他們都是同一家族的人，出生取名時就會先確定家族成員中都沒有使用過這個名字。假如家族有兩百人，並設定姓名為索引，那麼這個索引好像不可能會增加搜尋效率吧？因為在最壞情形下，還是必須搜尋每筆記錄才能找到指定的姓名。 除非常常搜尋對象是某幾個姓名，我們為這幾個姓名建立索引，搜尋時只針對這幾個姓名來搜尋，這樣肯定可以增加搜尋這幾個姓名時的效率。正如上面講的，資料表的索引是針對欄位的所有記錄，而不是幾個常被搜尋的記錄，既然全部都塞進索引裡面，那麼，以索引來作搜尋對象，跟直接以資料表來作搜尋對象，好像效率都一樣，以上面家族例子，建立索引跟不建立索引，在最壞情形下，都必須進行兩百次的資料比對，那麼為姓名欄位建立索引，豈不是多餘了？

其實索引的建立並不是像CANCER你所說的方法，它的建立是有學理根據的，不然建立索引作啥麼呢？！索引的建立，如果你有興趣的話，可以去看「資料結構與演算法」中有關（binary tree）二元樹的資料結構演算法，因為小弟對演算法實在很差勁< >，無法在此為你解說，如果你數學基礎夠好的話，應該可以瞭解其中的意義！< > ----------------------------------------------- Creation is the fundation of promotion.

我對資料庫並不是很熟悉。 不過早在十幾年前。 習慣寫Basic 因此用QB 自己寫資料庫結構。{非常痛苦} 裡面牽扯到 Double Link List （比較簡單)/ 二元樹 點點點...... 自己寫，別傻了！用現成的資料庫，效率好上太多了。 另外，您有一點疏忽了。 所謂索引簡要來說只不過是建立關鍵值(如姓名)的排序。 以方便您以最快的速度找到資料。 像是 二元搜尋法、基數搜尋法等等太多了。 並非從頭到尾的比對。 建議找本書來看。 ～～～～～～～～～～～ 難得聰明，常常糊塗。 ～～～～～～～～～～～ 發表人 - wameng 於 2005/05/30 20:25:52

你似乎把索引結構與資料庫結構給混在一起來想了, 誠如你這麼想的話, 真的有索引和沒有索引沒有兩樣,  其實不管這個欄位是不是具有唯一性的值或者重覆資料有多少, 當你不加索引結構下去找的話, 系統一定採循序比對的方式由頭至尾找到你要的那一筆, 假設有1萬筆, 要找的記錄在第1萬筆, 系統肯定要搜尋1萬次才會找到, 那要損耗多少時間, 但有索引時就不一樣了, 索引搜尋方式非常多, 早期資料庫常用的是二分法, 也就是如果欄位是數值, 系統會切一半來比對, 看搜尋值落在那一個範圍, 這樣可以大幅降低比對時間, 如果是字串, 先比對長度再比對內容, 至於系統如何做真的不值得我們去研究, 除非你想自創一種搜尋法!     問題來啦，我們在資料表中設定索引，是針對整個欄位來建立的，即針對欄位中所有的記錄，而不是"挑選"出欄位中部份的記錄來建立索引，這跟書本建立索引的方式並不相同。 另外你這段想法, 其實並不能歸類於索引, 這只能是附註型態, 作者對那些字詞他認為有需要加註說明, 所以列入注釋, 註解, 最標準的索引就是圖書索引系統, 各冊書均有其書目索引卡, 不可能說那本書比較重要給它一個索引, 那本不重要就不要索引, 索引中常用如ISBN, 作者, 出刊日, 書目.... 提到身份證的問題, 顯示你對索引存在很大的誤解, 並非唯一性的的記錄就無需索引(但也不代表就一定要索引), 就如上頭提到的, 如果沒有索引系統一定用循序比對, 有了索引則視那種資料庫提供何種方式的查詢設計來進行比對, 絶對可以提昇查詢效率, 建索引是不是多餘應該這樣想, 如果今天我對一個不太可能會進行查詢的欄位建立索引, 那就真的是多餘, 因為這樣只會降低資料庫異動的效能, 但如果要查詢的欄位是很重要的, 如姓名, 電話, ID..那建索引就不算是多餘, 還有如果你設計的資料都不想要查詢的話, 那索引幾乎可以省掉(這裡提幾乎不是絶對省掉, 請不要誤解) 以上提供你參考

很謝謝大大們的回應 我查過好幾個關於資料庫解說的網站，總算對索引多了一點點瞭解。我之所以想知道索引的工作原理，並不是懷疑索引的重要性，而是想知道建立索引的技巧，因為如果不懂得如何正確地建立索引，這才能把索引的效用提昇到最高，否則隨便建立索引後的執行效果只提昇 5%， 那麼乾脆不要建立索引算了。 有人認為只要建立索引就好，不必理會索引的工作原理，但我從網路上找的資料卻顯示出瞭解索引工作原理的重要性，有些網站還提供建立索引的訣竅，知道這些訣竅的人之所以知道，完全是因為他們瞭解索引的工作原理。 我把自己查到的資料簡單整理一下（以MS SQL 2000 為例） 1.預設情形下，主鍵亦是clustered index，但可更改為nonclustered index。 2.設定為clustered index 的欄位決定了資料在檔案中的排序。 3.欄位內容常常更改的欄位，最好不要設為clustered index。 4.clustered index 若由多欄位組成，其他每個index的體積將連帶增加。 5.若搜尋範圍具有連續性，則被搜尋欄位最好設為clustered index。 6.若作零散式搜尋，則被搜尋欄位最好設為nonclustered index。 以上所謂好，指有更好效率。我還查到更多的，省略不列出來了。 以下這個解說 MS SQL Server 索引結構的網頁真不錯： http://www.akadia.com/services/sqlsrv_data_structure.html 可惜的是只能看到這一頁，如果輸入 http://www.akadia.com/services 將會得到 "您無權進入"的回應，搞不定是會員才能進去。 大家都很熱心幫我，但我不知道該推誰，所以，乾脆不推就自行結案吧。