｜關聯式資料庫｜Key｜資料正規化｜SQL (1)｜SQL (2)｜SQL (3)｜SQL (4)｜SQL (5)｜
資料庫簡介

Index

Index 的優點
　先看看這個例子：請在下表中找出學號為「75120」者的成績。
　從表格的開頭逐筆尋找，您將在第 7 筆的位置發現目標，您總共找了 7 次。
　若針對「學號」這一欄建立「索引」（Index）的話，則會像以下這個樣子：除了右側的原始表格之外，還會多出一個如左邊這樣的 index table；在 index table 中，學號已經被排序過了，但它仍記錄著每個學號與原始表格之間的對應關係。
　同樣要找出學號為「75120」者的成績，有了 index 之後將有些不同，我們改從 index table 中著手。
　由於 index table 中的資料已經被排序過了，我們不必自表格開頭循序尋找。以「二分法」為例，8 筆資料取半數，直接看 index table 的第 4 筆記錄（75302）；我們的目標（75120）比它小，所以再取 4 的半數，看看第 2 筆記錄（75120），結果就找到了。整個過程中，我們只找了 2 次。
　有了 index 以後，不見得每次都會比較快，若是要找「75312」的話，在沒有 index 的情況下，反而可以一次命中目標。
　那麼 index 對搜尋速度到底有沒有幫助呢？我們以數學的觀點來看這個問題。假如某個表格有 N 筆記錄，在沒有 index 的情況下，想找到特定記錄，最快的是 1 次（目標恰好在開頭處），最慢的則是 N 次（目標恰好在末尾處），平均得花上 N/2 次才能找到目標。
　有了 index，再使用「二分法」來搜尋的話，因為每找一次，即可去除一半的資料，所以平均只要 Log2N 次即可。
　若某個表格有 1024 筆記錄，沒 index 的話，平均得找 512 次（1024/2）才能找到；有了 index 之後，則可以在 10 次（Log21024）以內交差。

Index 的缺點
　效率差很多吧！真是這樣的話，我們將表格中的每個欄位都設為 index 的話，豈不是最好了嗎？這倒不見得，index 雖然有加速搜尋的優點，但也有以下兩項缺點：
1. 需要更多資料儲存的空間
　本來只有一個原始表格，當我們將「學號」設為 index 之後，就多了一個 index table；若再將「姓名」設為 index 的話，又會多出一個 index table 來。在儲存成本日漸下滑的今日，您或許不太介意這種問題，但第二項缺點則是您不可忽視的。
2. 增加資料異動所需的時間
　當我們在原始表格中加入一筆「75121」的成績記錄時，相關的 index table 也需要跟著同步更新。越多欄位被設為 index 的話，需要同步更新的 index table 也就更多，這樣一來，就會花費更多資料處理的時間。

用不用 Index ？
　Index 的使用有提升搜尋效率的優點，但異動時間與儲存空間的耗費卻也是不可漠視的缺點。那麼，到底用不用 index 呢？其實當只有少量資料時，index 的好處與壞處都讓人感受不到，唯有在面對大量資料時，您才需要煩惱這個問題。
【我會用 Index】
　當我將全高雄縣的師生基本資料建檔，且置放於同一表格時，這可能會有近十萬筆資料，不用 index 是不成的了。但要怎麼用才適當呢？首先，我會將「身分證字號」這種確定不重複的欄位設為 Primary key（同時具有 index 效果）；其次，將經常被用來檢索的欄位設為 index key，如「學校代號」。至於像「地址」這種又長又是中文內容的欄位，最好別打它的主意。
【我不用 Index】
　有些行政應用系統注重資料安全性的問題，操作人員的一舉一動都會被記錄下來；在使用尖峰時段，同一秒之中就會有多筆資料同時被寫入，一天下來可能會有數十萬筆資料。面對這種資料表，我不會加上任何 index，因為它如同流水帳一般，不斷地新增資料，但無需進行異動。
　像這樣的資料表，我會以「天」為單位，每天分別建立一個表格，日後需要查詢歷史資料時，再將舊表格取出來用。您或許會問：光是一天的資料就有數十萬筆了，沒有 index key 的話，查詢的效率豈不是很糟糕嗎？沒關係，因為它是歷史資料，已經沒有異動的需要了，這時候再為它加上 index key 的話，就利遠大於弊了。
｜關聯式資料庫｜Key｜資料正規化｜SQL (1)｜SQL (2)｜SQL (3)｜SQL (4)｜SQL (5)｜