哈希表和哈希函數是大學數據結構中的課程，實際開發中我們經常用到Hashtable這種結構，當遇到鍵-值對存儲，采用Hashtable比ArrayList查找的性能高。為什麼呢？我們在享受高性能的同時，需要付出什麼代價(這幾天看紅頂商人胡雪巖，經典台詞：在你享受這之前，必須受別人吃不了的苦，忍受別人受不了的屈辱)，那麼使用Hashtable是否就是一樁無本萬利的買賣呢？就此疑問，做以下分析，希望能拋磚引玉。
1)hash它為什麼對於鍵-值查找性能高
學過數據結構的，都應該曉得，線性表和樹中，記錄在結構中的相對位置是隨機的，記錄和關鍵字之間不存在明確的關系，因此在查找記錄的時候，需要進行一系列的關鍵字比較，這種查找方式建立在比較的基礎之上，在.Net中(Array,ArrayList,List)這些集合結構采用了上面的存儲方式。
比如，現在我們有一個班同學的數據，包括姓名，性別，年齡，學號等。假如數據有
姓名 性別 年齡 學號 張三 男 15 1 李四 女 14 2 王五 男 14 3
假如，我們按照姓名來查找，假設查找函數FindByName(string name);
1)查找“張三”
只需在第一行匹配一次。
2)查找"王五"
在第一行匹配，失敗，
在第二行匹配，失敗，
在第三行匹配，成功
上面兩種情況，分別分析了最好的情況，和最壞的情況，那麼平均查找次數應該為 (1+3)/2=2次，即平均查找次數為(記錄總數+1)的1/2。
盡管有一些優化的算法，可以使查找排序效率增高，但是復雜度會保持在log2n的范圍之內。
如何更更快的進行查找呢？我們所期望的效果是一下子就定位到要找記錄的位置之上，這時候時間復雜度為1，查找最快。如果我們事先為每條記錄編一個序號，然後讓他們按號入位，我們又知道按照什麼規則對這些記錄進行編號的話，如果我們再次查找某個記錄的時候，只需要先通過規則計算出該記錄的編號，然後根據編號，在記錄的線性隊列中，就可以輕易的找到記錄了 。
注意，上述的描述包含了兩個概念，一個是用於對學生進行編號的規則，在數據結構中，稱之為哈希函數，另外一個是按照規則為學生排列的順序結構，稱之為哈希表。
仍以上面的學生為例，假設學號就是規則，老師手上有一個規則表，在排座位的時候也按照這個規則來排序，查找李四，首先該教師會根據規則判斷出，李四的編號為2，就是在座位中的2號位置，直接走過去，“李四，哈哈，你小子，就是在這！”
看看大體流程:
