雜湊是在記錄的儲存位置和它的關鍵字之間建立乙個確定的對應關係f，使得每個關鍵字key對應乙個儲存位置f(key)。建立了關鍵字與儲存位置的對映關係，公式如下：
設所有可能出現的關鍵字集合記為u(簡稱全集)，實際發生(即實際儲存)的關鍵字集合記為k（|k|比|u|小得多）。
雜湊方法是使用函式f將u對映到表t[0..m-1]的下標上（m=o(|u|)）。這樣以u中關鍵字為自變數，以f為函式的運算結果就是相應結點的儲存位址。從而達到在o(1)時間內就可完成查詢。
其中：雜湊的概念屬於查詢，它不以關鍵字的比較為基本操作，採用直接定址技術。
在最壞情況下，雜湊表的查詢和刪除的最壞時間代價為o(n),但是在實際中，雜湊表的效能是很好的，在一些合理的假設下，雜湊表的查詢和刪除操作的平均時間代價為o(1)。
在說直接定址法之前，先舉個例子：
現在有10個門，並且從1到10標好了號碼，你手中有5號門的鑰匙，那如何開啟第五號門呢？肯定不是乙個乙個的去試，而是直接去開第5號門。
list_a = [1,2,3,4]
list_a[2]
>>>3
如果我們現在要對0-100歲的人口數字統計表，那麼我們對年齡這個關鍵字就可以直接用年齡的數字作為位址。此時f(key) = key。位址
年齡人數000
500萬011
600萬022
450萬
......
...20
201500萬
......
...這個時候，我們可以得出這麼個雜湊函式：
f(0) = 0，f(1) = 1，……，f(20) = 20。
這個是根據我們自己設定的直接定址來的。人數我們可以不管，我們關心的是如何通過關鍵字找到位址。
如果我們現在要統計的是80後出生年份的人口數，那麼我們對出生年份這個關鍵字可以用年份減去1980來作為位址。此時f (key) = key-1980。位址
出生年份
人數00
1980
500萬
011981
600萬
021982
450萬
......
...20
2000
1500萬
......
...假如今年是2023年，那麼2023年出生的人就是20歲了，此時 f(2000) = 2000 - 1980，可以找得到位址20，位址20裡儲存了資料「人數500萬」。
f(key) = a × key + b這樣的雜湊函式優點就是簡單、均勻，也不會產生衝突，但問題是這需要事先知道關鍵字的分布情況，適合查詢表較小且連續的情況。由於這樣的限制，在現實應用中，直接定址法雖然簡單，但卻並不常用。
除留餘數法此方法為最常用的構造雜湊函式方法。對於雜湊表長為m的雜湊函式公式為：
f( key ) = key mod p ( p ≤ m )mod是取模（求餘數）的意思。事實上，這方法不僅可以對關鍵字直接取模，也可在摺疊、平方取中後再取模。
乙個例子
有乙個關鍵字，它有12個記錄，現在我們要針對它設計乙個雜湊表。如果採用除留餘數法，那麼可以先嘗試將雜湊函式設計為如下方法：
f(key) = key mod 12比如29 mod 12 = 5，所以它儲存在下標為5的位置。下標0
1234
5678
91011關鍵字
1225
3815
1629
7867
5621
2247
不過這也是存在衝突的可能的，因為12 = 2×6 = 3×4。如果關鍵字中有像18(3×6)、30(5×6)、42(7×6)等數字，它們的餘數都為6，這就和78所對應的下標位置衝突了。
甚至極端一些，對於下圖的關鍵字，如果我們讓p為12的話，就可能出現下面的情況，所有的關鍵字都得到了0這個位址數，這未免也太糟糕了點。下標0
0000
0000
000關鍵字
1224
3648
6072
8496
108120
132144
但是我們如果不選用p=12來做除留餘數法，而選用p=11，則結果如下：下標1
2345
6789
1001關鍵字
1224
3648
6072
8496
108120
132144
這個時候就只有12和144有衝突，相對來說，就要好很多了。
如何合理選取p值
使用除留餘數法的乙個經驗是，若雜湊表表長為m，通常p為小於或等於表長（最好接近m)的最小質數或不包含小於20質因子的合數。這句話怎麼理解呢？再舉個例子：某雜湊表的長度為100，雜湊函式h(k)=k%p,則p通常情況下最好選擇哪個呢？
a、91 b、93 c、97 d、99
實踐證明，當p取小於雜湊表長的最大質數時，產生的雜湊函式較好。所以選97，因為它是離長度值最近的最大質數。
HANA資料庫為何如此之快
原文標題是how sap hana is such a fast database，不過作者的觀點是hana的快主要源自硬體的發展，而且hana並非適合所有的應用場景。不過我關注的恰好是結論之外的部分。儲存硬體的提公升，從物理磁碟到ssd,記憶體，相應的資料庫查詢方式也發生了變化。當資料庫使用傳統的...
HANA資料庫為何如此之快
原文標題是how sap hana is such a fast database，不過作者的觀點是hana的快主要源自硬體的發展，而且hana並非適合所有的應用場景。不過我關注的恰好是結論之外的部分。儲存硬體的提公升，從物理磁碟到ssd,記憶體，相應的資料庫查詢方式也發生了變化。當資料庫使用傳統的...
提高質量為何如此之難
提高質量為何如此之難 precision cribbage 的故事說明，符合需求 並非是質量全部含義 除非你接受的是某種關於需求的非傳統定義。這個故事同時也說明，基於錯誤的數量來定義質量也是不全面的 這方面的例子有 所謂質量，就是指沒有任何錯誤。雖然實際上這類定義不堪一駁，但是許多年來它們一直是人們...