資料在磁碟上是以塊的形式儲存的。為確保對磁碟操作的原子性，訪問資料的時候會一併訪問所有資料塊。磁碟上的這些資料塊與鍊錶類似，即它們都包含乙個資料段和乙個指標，指標指向下乙個節點（資料塊）的記憶體位址，而且它們都不需要連續儲存（即邏輯上相鄰的資料塊在物理上可以相隔很遠）。
鑑於很多記錄只能做到按乙個字段排序，所以要查詢某個未經排序的字段，就需要使用線性查詢，即要訪問n/2個資料塊，其中n指的是乙個表所涵蓋的所有資料塊。如果該欄位是非鍵欄位（也就是說，不包含唯一值），那麼就要搜尋整個表空間，即要訪問全部n個資料塊。
然而，對於經過排序的字段，可以使用二分查詢，因此只要訪問log2 n個資料塊。同樣，對於已經排過序的非鍵字段，只要找到更大的值，也就不用再搜尋表中的其他資料塊了。這樣一來，效能就會有實質性的提公升。
索引是對記錄按照多個字段進行排序的一種方式。對錶中的某個字段建立索引會建立另一種資料結構，其中儲存著字段的值，每個值又指向與它相關的記錄。這種索引的資料結構是經過排序的，因而可以對其執行二分查詢。
索引的缺點是占用額外的磁碟空間。因為索引儲存在myisam資料庫中，所以如果為同乙個表中的很多欄位都建立索引，那這個檔案可能會很快膨脹到檔案系統規定的上限。
首先，來看乙個示例資料庫表的模式：
欄位名
資料型別
在磁碟上的大小
id (
primary
key)
unsigned
int 4位元組
firstname
char(50
)50位元組lastname
char(50
)50位元組emailaddress
char
(100
)100
位元組
char而不用varchar是為了精確地描述資料占用磁碟的大小。這個示例資料庫中包含500萬行記錄，而且沒有建立索引。接下來我們就分析針對這個表的兩個查詢：乙個查詢使用id（經過排序的鍵字段），另乙個查詢使用firstname（未經排序的非鍵字段）。
對於這個擁有r = 5 000 000條記錄的示例資料庫，在磁碟上要為每條記錄分配 r = 204位元組的固定儲存空間。這個表儲存在myisam資料庫中，而這個資料庫預設的資料庫塊大小為 b = 1024位元組。於是，我們可計算出這個表的分塊因數為 bfr = (b/r) = 1024/204 = 5，即磁碟上每個資料塊儲存5條記錄。那麼，儲存整個表所需的資料塊數就是 n = (r/bfr) = 5000000/5 = 1 000 000。
使用線性查詢搜尋id欄位——這個欄位是鍵字段（每個欄位的值唯一），需要訪問 n/2 ＝ 500 000個資料塊才能找到目標值。不過，因為這個欄位是經過排序的，所以可以使用二分查詢法，而這樣平均只需要訪問log2 1000000 = 19.93 = 20 個塊。顯然，這會給效能帶來極大的提公升。
再來看看firstname欄位，這個欄位是未經排序的，因此不可能使用二分查詢，況且這個欄位的值也不是唯一的，所以要從表的開頭查詢末尾，即要訪問 n = 1 000 000個資料塊。這種情況通過建立索引就能得到改善。
如果一條索引記錄只包含索引欄位和乙個指向原始記錄的指標，那麼這條記錄肯定要比它所指向的包含更多字段的記錄更小。也就是說，索引本身占用的磁碟空間比原來的表更少，因此需要遍歷的資料塊數也比搜尋原來的表更少。以下是firstname欄位索引的模式：
欄位名
資料型別
在磁碟上的大小
firstname
char(50
)50位元組（記錄指標）
special
4位元組
對於這個擁有r = 5 000 000條記錄的示例資料庫，每條索引記錄要占用 r = 54位元組磁碟空間，而且同樣使用預設的資料塊大小 b = 1024位元組。那麼索引的分塊因數就是 bfr = (b/r) = 1024/54 = 18。最終這個表的索引需要占用 n = (r/bfr) = 5000000/18 = 277 778個資料塊。
現在，再搜尋firstname欄位就可以使用索引來提高效能了。對索引使用二分查詢，需要訪問 log2 277778 = 18.09 = 19個資料塊。再加上為找到實際記錄的位址還要訪問乙個資料塊，總共要訪問 19 + 1 = 20個資料塊，這與搜尋未索引的表需要訪問277 778個資料塊相比，不啻於天壤之別。
建立索引要額外占用磁碟空間（比如，上面例子中要額外占用277 778個資料塊），建立的索引太多可能導致磁碟空間不足。因此，在建立索引時，一定要慎重選擇正確的字段。
由於索引只能提高搜尋記錄中某個匹配欄位的速度，因此在執行插入和刪除操作的情況下，僅為輸出結果而為字段建立索引，就純粹是浪費磁碟空間和處理時間了；這種情況下不用建立索引。另外，由於二分查詢的原因，資料的基數性（cardinality）或唯一性也非常重要。對基數性為2的字段建立索引，會將資料一分為二，而對基數性為1000的字段，則同樣會返回大約1000條記錄。在這麼低的基數性下，索引的效率將減低至線性查詢的水平，而查詢優化器會在基數性大於記錄數的30%時放棄索引，實際上等於索引純粹只會浪費空間。
查詢優化器的原理查詢優化中最核心的問題就是精確估算不同查詢計畫的成本。優化器在估算查詢計畫的成本時，會使用乙個數學模型，該模型又依賴於對每個查詢計畫中涉及的最大資料量的基數性（或者叫重數）的估算。而對基數性的估算又依賴於對查詢中謂詞選擇因數（selection factor of predicates）的估算。過去，資料庫系統在估算選擇性時，要使用每個欄位中值的分布情況的詳盡統計資訊，比如直方圖。這種技術對於估算孤立謂詞的選擇符效果很好。然而，很多查詢的謂詞是相互關聯的，例如
select count(*) from r where r.make='honda' and r.model='accord'。查詢謂詞經常會高度關聯（比如，model='accord'的前提條件是make='honda'），而估計這種關聯的選擇性非常困難。查詢優化器之所以會選擇低劣的查詢計畫，一方面是因為對基數性估算不准，另一方面就是因為遺漏了很多關聯性。而這也是為什麼資料庫管理員應該經常更新資料庫統計資訊（特別是在重要的資料載入和解除安裝之後）的原因。（譯自維基百科：
資料庫索引工作原理
譯者按 今天在翻譯時無意中搜尋到stackoverflow中的這篇文章 問答 覺得有必要翻譯出來。不僅因為文章本身寫得精彩，更重要的是它昭示了乙個寫文章 特別是技術文章 的重要法則 5w1h。原文在此 how does database indexing work?資料在磁碟上是以塊的形式儲存的。為...
資料庫索引及其工作原理
我們通過乙個簡單的例子來開始教程，解釋為什麼我們需要資料庫索引。假設我們有乙個資料庫表 employee，這個表有三個字段 列 分別是 employee name employee age 和employee address。假設表employee 有上千行資料。現在假設我們要從這個表中查詢出所有名...
資料庫索引優化原理，索引的工作機制
我們通過乙個簡單的例子來開始教程，解釋為什麼我們需要資料庫索引。假設我們有乙個資料庫表 employee，這個表有三個字段 列 分別是 employee name employee age 和employee address。假設表employee 有上千行資料。現在假設我們要從這個表中查詢出所有名...