SQLSERVER在索引下如何找到哈希值的随想
测试环境：SQLSERVER2005 开发者版
真的不好意思，我做实验的时候到最后还是没有找到这个问题的答案
问题是这样的：
当通过聚集索引查找和非聚集索引查找的时候，通过哈希码来匹配，然后找到相应记录的
既然通过哈希码来匹配，那么就需要一个hash bucket把所有索引页面的所有key/value全部加载到hash bucket
既然要全部加载到hash bucket就需要读取所有的索引页
我的测试脚本，我使用SET STATISTICS IO ON来测试是否有读取索引页的情况，但是到最后还是找不到规律
聚集索引表的情况
非聚集索引表的情况
今天中午跟高文佳兄讨论了很长时间，我把关键讨论部分贴出来，大家参考参考，讨论的最后结果是：还没有解释到keyhashvalue字段实际的作用
ō笑东风ō 9:27:10
对了 你那个hash的问题
ō笑东风ō 9:27:21
ō笑东风ō 9:27:21
感觉你研究的方向不对
ō笑东风ō 9:28:05
当通过聚集索引查找和非聚集索引查找的时候，通过哈希码来匹配，然后找到相应记录的
桦少 9:28:53
请指教
ō笑东风ō 9:29:00
查找时不会使用hash来查找 因为hash值没有排序 无法最快查找 ![]()
桦少 9:29:18 ![]()
ō笑东风ō 9:29:20 应该是按照key来查找
桦少 9:33:52
ō笑东风ō 9:29:20
应该是按照key来查找
桦少 9:33:55
说说你的思路
ō笑东风ō 9:34:18
在索引里已经按照KEY排序 对吧
ō笑东风ō 9:34:34
而按照key排序 能最快找到想要的值
桦少 9:35:38
key排序有争议
桦少 9:35:42
又怎样
桦少 9:35:58
你还没有说清楚
ō笑东风ō 9:37:21
先说key查找的
我记得你有篇blog里说过hashjoin
桦少 9:39:38
哪三个经典连接没有写
ō笑东风ō 9:40:56
反正我的观点是key查找最快 无须再使用hash来定位
ō笑东风ō 9:41:26
而只有在hash join才会用到hash
笑东风ō 9:40:56
反正我的观点是key查找最快 无须再使用hash来定位
而只有在hash join才会用到hash
桦少 12:50:35
你想好啦吗
ō笑东风ō 12:51:57
嗯 我还是认为聚簇索引和非聚簇索引只存在key lookup
桦少 12:55:46
key lookup
的原理是什么
桦少 12:55:52
操作步骤是怎样的
桦少 12:55:56
你知道吗
ō笑东风ō 12:59:31
就是平衡树的原理
桦少 13:00:31
好
ō笑东风ō 13:00:38
使用平衡树 对上百万的INT值进行查找只需要4步
桦少 13:00:58
你查找的时候是否需要从磁盘读取索引页面到内存
ō笑东风ō 13:01:05
对
桦少 13:01:06
先不说他用多少步
桦少 13:01:08
性能有多好
桦少 13:01:26
从磁盘读取整个表的索引页面到内存
桦少 13:01:29
整个表
桦少 13:01:41
然后构成你说的所谓的平衡树
ō笑东风ō 9:29:20
应该是按照key来查找
桦少 9:33:55
说说你的思路
ō笑东风ō 9:34:18
在索引里已经按照KEY排序 对吧
ō笑东风ō 9:34:34
而按照key排序 能最快找到想要的值
桦少 9:35:38
key排序有争议
桦少 9:35:42
又怎样
桦少 9:35:58
你还没有说清楚
ō笑东风ō 9:37:21
先说key查找的
我记得你有篇blog里说过hashjoin
桦少 9:39:38
哪三个经典连接没有写
ō笑东风ō 9:40:56
反正我的观点是key查找最快 无须再使用hash来定位
ō笑东风ō 9:41:26
而只有在hash join才会用到hash
笑东风ō 9:40:56
反正我的观点是key查找最快 无须再使用hash来定位
而只有在hash join才会用到hash
桦少 12:50:35
你想好啦吗
ō笑东风ō 12:51:57
嗯 我还是认为聚簇索引和非聚簇索引只存在key lookup
桦少 12:55:46
key lookup
的原理是什么
桦少 12:55:52
操作步骤是怎样的
桦少 12:55:56
你知道吗
ō笑东风ō 12:59:31
就是平衡树的原理
桦少 13:00:31
好
ō笑东风ō 13:00:38
使用平衡树 对上百万的INT值进行查找只需要4步
桦少 13:00:58
你查找的时候是否需要从磁盘读取索引页面到内存
ō笑东风ō 13:01:05
对
桦少 13:01:06
先不说他用多少步
桦少 13:01:08
性能有多好
桦少 13:01:26
从磁盘读取整个表的索引页面到内存
桦少 13:01:29
整个表
桦少 13:01:41
然后构成你说的所谓的平衡树
桦少 13:01:46
对吧
ō笑东风ō 13:02:06
对
桦少 13:02:52
我的问题就是这个
桦少 13:03:01
我用statictis io
桦少 13:03:10
看不出他会读取所有的索引页面
ō笑东风ō 13:04:25
一次seek 当然不会读取所有的页面
ō笑东风ō 13:04:48
只有scan才会读取所有页面
桦少 13:05:36
你还是不明白我问的问题
桦少 13:06:18
我说的是索引页
桦少 13:06:26
不是数据页
ō笑东风ō 13:06:45
索引也一样
ō笑东风ō 13:06:50
等等我给你做个demo
桦少 13:08:00
还有 ō笑东风ō 13:08:30
我现在有[BackupTestDB].[dbo].[TB1] 表中数据有245461条
桦少 13:08:43
你说用二叉树
ō笑东风ō 13:08:44 ![]()
桦少 13:08:47
如果是这样
桦少 13:08:59
那么，keyhashvalue就没有意义了
ō笑东风ō 13:09:06
不是二叉树 是B树
桦少 13:09:15 ![]()
桦少 13:09:23
b树 桦少 13:09:51
所以我从hash bucket的角度去思考
ō笑东风ō 13:10:22
hash桶这个概念是为了HASH JOIN才产生的
桦少 13:10:36
如果用b树，从第一个最左边的叶子节点开始从磁盘读取索引页面，组装一棵B树
ō笑东风ō 13:11:05
继续
桦少 13:11:23
如果是这样，keyhashvalue这个字段根本不需要
桦少 13:12:12
用到key![]()
alue的都可以用桶这个概念啊
桦少 13:12:19
我觉得
桦少 13:12:47
我觉得不用死磕书本
桦少 13:13:06
死磕书本等于读死书
ō笑东风ō 13:14:28![]()
ō笑东风ō 13:14:28
桦少 13:14:49 ![]()
桦少 13:15:58
我以前做实验的时候也看到过keyhashvalue全部为null
桦少 13:16:47
想写在SQLSERVER聚集索引与非聚集索引的再次研究（上）文章的最后面的
桦少 13:16:58
但是因为解释不了这个现象
桦少 13:17:01
最后没有写
桦少 13:19:42
为什麽我提出这个想法
桦少 13:19:52
其实我也是从性能和速度考虑的
ō笑东风ō 13:20:09
骚等
桦少 13:20:21
我的想法是：sqlserver有可能不用你刚才说的B树来找记录
ō笑东风ō 13:20:31
我怀疑这个HASHvalus是为了在seek时做比较用的
桦少 13:20:45
我画图给你看
桦少 13:22:42
当我用聚集索引查找的时候
桦少 13:23:11
key的字段是id
桦少 13:23:25
表中的字段是id
桦少 13:23:32
id是聚集索引字段
桦少 13:23:50
value是数据页面号
桦少 13:24:12
我要找id为9的那条记录
桦少 13:24:58
等一下
桦少 13:25:02
图还没画好
桦少 13:26:27 ![]()
桦少 13:26:51
我需要将索引页69，88，102读取到内存
桦少 13:26:57
构成一棵b树
桦少 13:27:13
从左到右，从上到下查找
桦少 13:27:30
直至找到key为9那条记录
桦少 13:27:59
如果我select的是id为3的那条记录
桦少 13:28:17
我就不用读取索引页88，102读取到内存
桦少 13:28:23
只需要读取索引页面69