當(dāng)一個key-value鍵值對傳遞給一個哈希函數(shù)的時候,經(jīng)過哈希函數(shù)的計算之后,根據(jù)結(jié)果會把key-value鍵值對放在合適的hash buckets(哈希存儲桶)里
舉個栗子
我們假設(shè)對10取模( % 10 )就是哈希函數(shù)。如果key-value鍵值對的key是1525 ,傳遞到哈希函數(shù),那么1525 會存放在第五個bucket里
因為5 as 1525 % 10 = 5。
同樣,537 會存放在第七個bucket ,2982 會存放在第二個bucket ,依次類推
同樣,在hash index里面,哈希索引列會被傳遞給哈希函數(shù)做匹配(類似于java里面的HashMap的Map操作),匹配成功之后,
索引列會被存儲在匹配到的hash bucket里面的表里,這個表里會有實際的數(shù)據(jù)行指針,再根據(jù)實際的數(shù)據(jù)行指針查找對應(yīng)的數(shù)據(jù)行。
概括來說,要查找一行數(shù)據(jù)或者處理一個where子句,SQL Server引擎需要做下面幾件事
1、根據(jù)where條件里面的參數(shù)生成合適的哈希函數(shù)
2、索引列進行匹配,匹配到對應(yīng)hash bucket,找到對應(yīng)hash bucket意味著也找到了對應(yīng)的數(shù)據(jù)行指針(row pointer)
3、讀取數(shù)據(jù)
哈希索引比起B(yǎng)樹索引簡單,因為它不需要遍歷B樹,所以訪問速度會更快
哈希函數(shù)和相應(yīng)語法的例子
CREATE TABLE dbo.HK_tbl
(
[ID] INT IDENTITY(1, 1)
NOT NULL
PRIMARY KEY NONCLUSTERED HASH WITH ( BUCKET_COUNT = 100000 ) ,
[Data] char(32) COLLATE Latin1_General_100_BIN2
NULL ,
[dt] datetime NOT NULL,
)
WITH (
MEMORY_OPTIMIZED =
ON,
DURABILITY =
SCHEMA_AND_DATA);
在SQL Server 2014里面,內(nèi)存優(yōu)化表創(chuàng)建完之后就不能再加哈希索引了,但是在 SQL Server 2016 里支持表創(chuàng)建完之后添加哈希索引,不過
添加哈希索引是一個離線操作。
哈希索引的Bucket 數(shù)量
( BUCKET_COUNT = 100000 )定義了哈希索引能夠使用的BUCKET數(shù)量,這個Bucket 是固定的并且由用戶指定Bucket 數(shù)量,
而不是執(zhí)行查詢的時候由SQL Server決定生成的Bucket 數(shù)量。BUCKET數(shù)量總是2的次方的四舍五入( 1024, 2048, 4096 etc..)
SQL Server2014的哈希索引其實跟MySQL的自適應(yīng)哈希索引原理其實差不多,都是為了擺脫B樹的束縛,使查找效率更快
How does a relational database work這篇文章也有描述hash join的原理,大家可以看一下
您可能感興趣的文章:- sqlserver索引的原理及索引建立的注意事項小結(jié)
- SqlServer索引的原理與應(yīng)用詳解
- SQL Server 索引介紹
- SQLSERVER全文目錄全文索引的使用方法和區(qū)別講解
- SQL Server 聚集索引和非聚集索引的區(qū)別分析
- SQLSERVER 創(chuàng)建索引實現(xiàn)代碼
- SQLSERVER聚集索引和主鍵(Primary Key)的誤區(qū)認識
- sqlserver 索引的一些總結(jié)
- SQL Server全文索引服務(wù)
- SQL Server索引的原理深入解析