昨天中午跟高文佳童鞋讨论了KeyHashValue的作用，到最后还是没有讨论出结果
虽然对于keyhashvalue的研究还有很多问题还没有解决，但是基本可以确定“keyhashvalue是用来锁定资源的”
而不是我之前说的，在seek的时候根据这个KeyHashValue来快速查找到对应的记录
误导大家了，真的不好意思！！！！
资源 说明
RID 用于锁定堆（heap）中的某一行
KEY 用于锁定索引上的某一行，或者某个索引键
PAGE 锁定数据库中的一个8KB页，例如数据页或索引页
EXTENT 一组连续的8页（区）
HOBT 锁定整个堆或B树的锁
TABLE 锁定包括所有数据和索引的整个表
FILE 数据库文件
APPLICATION 应用程序专用的资源
METADATA 元数据锁
ALLOCATION_UNIT 分配单元
DATABASE 整个数据库
KEY是靠生成的这个KeyHashValue来进行锁定索引中的行
KEY 用于锁定索引上的某一行
为什么需要这个KeyHashValue
我觉得从C#的多线程同步来理解KeyHashValue会更加好
例如：
lock 语句 lock 确保当一个线程位于代码的临界区时，另一个线程不进入临界区。如果其他线程试图进入锁定的代
码，则它将一直等待（即被阻止），直到该对象被释放，大家可以把同步对象理解为KeyHashValue
网上有很多相关的文章：
例如
建立索引的时候为什麽有900bytes的限制
为了性能，不可能让您在比较大的数据类型下，而且存储了非常多的数据的字段上建立索引
因为这样做的话，要计算出KeyHashValue就会非常消耗性能
这篇文章：Improvement in minimizing lockhash key collisions in SQL Server 2008R2 and its impact on concurrency
Since the key to a row could be as large as 900 bytes, using the real key values would have inflicted larger memory consumption.
引入
The solution to this problem was found when designing SQL server 7.0 in 1996 and 1997 by using the key of the row and apply
a hash algorithm to it which then results in a 6 byte long lockhash value
我将这些文章整理到我的文章里：undocumented virtual column %%lockres%%
在SQLSERVER2005下跟SQLSERVER2012下，建立相同的聚集索引，你会看到在SQL2005下，表的聚集索引页面有KeyHashValue
但是在SQL2012下，表的聚集索引页面的KeyHashValue列全部为NULL
由于我没有SQL2008，所以没有测试SQL2008，估计从SQL2008开始，KeyHashValue开始有些变化了
在SQL2005里，你使用dbcc page查看数据页面，数据页面里的每行记录是没有显示KeyHashValue的，不知道要打开哪个跟踪标记才能看到
在SQL2005里唯一能看到数据页面中的keyhashvalue只有使用%%lockres%%
而在SQL2012，不用做任何设置，使用dbcc page就可以看到KeyHashValue
当然也可以用%%lockres%%：
1 SELECT %%lockres%% AS '数据页的keyhashvalue' FROM 表名
页面126是数据页面
1 DBCC TRACEON(3604,-1) 2 GO 3 DBCC PAGE(testhashkey,1,126,3) 4 GO
Slot 0 Offset 0x0 Length 0 Length (physical) 0
KeyHashValue = (8194443284a0)
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
SQL2012最大的改进是提示非常清晰，而且以前的SQLSERVER版本没有显示出来的东西都给你显示出来了，
这样就不用做那么多系统表的表连接，如果是SQL2012以前版本要查看某一个信息的时候又要做
这个系统表的表连接又要做那个表的表连接才能得出这个自己想看的东西，非常繁琐
例如如下改进：
聚集索引页面的显示，SQL2005是没有Row Size这一列的
下面的所有测试都是基于SQLSERVER2005 SP4 个人开发版
聚集索引
创建聚集索引的时候无论是唯一还是不唯一都会产生KeyHashValue
但是为了实验的方便，我这里只创建唯一聚集索引，因为不唯一的话会产生range locks不方便查看结果
详细请参考文章：Range locks
脚本：
1 USE master 2 GO 3 CREATE DATABASE testhashkey 4 GO 5 6 USE testhashkey 7 GO 8 9 -------------------------------------------- 10 --测试聚集索引 11 CREATE TABLE testcluster 12 ( 13 a NVARCHAR(3800) NOT NULL , 14 b INT NOT NULL 15 ) 16 GO 17 18 --这里一定要是唯一的 19 CREATE UNIQUE CLUSTERED INDEX ucl ON testcluster(b) 20 GO 21 22 INSERT testcluster 23 SELECT CAST(11 AS VARCHAR(10))+replicate('a', 3500),1 UNION ALL 24 SELECT CAST(22 AS VARCHAR(10))+replicate('a', 3500),2