解剖 SQLSERVER 第十三篇 Integers在行 压缩 和页 压缩 里的 存储 格式 揭秘 （译） http://improve.dk/the-anatomy-of-row-amp-page-compressed-integers/ 当解决OrcaMDF对行 压缩 的支持的时候，视图解析整数的时候遇到了一些挑战。 和正常的未 压缩 整数
解剖 SQLSERVER 第十三篇 Integers在行 压缩 和页 压缩 里的 存储 格式 揭秘 （译）
http://improve.dk/the-anatomy-of-row-amp-page-compressed-integers/
当解决OrcaMDF对行 压缩 的支持的时候，视图解析整数的时候遇到了一些挑战。
和正常的未 压缩 整数 存储 不同的是这些都是可变长度--这意味着1个整数的值50只占用1个字节，而不是通常的4个字节。
这些不是新功能了，大家可以看一下vardecimal他被 存储 为可变长度。然而不同的是两者 存储 在磁盘上的数据的方式。
注意虽然我只是实现行 压缩 ，他跟页面 压缩 中使用的行 压缩 是一样的，并没有区别
大家可以看一下《深入解析SQL Server 2008 笔记》里面有行 压缩 和页 压缩 的详细解释
Tinyint
Tinyint在 压缩 后和 压缩 前基本是一样的（tinyint：从0到255的整数数据， 存储 大小为 1 字节）只有一个例外情况，当数值是0的时候如果开启了行 压缩 将不占用任何字节，
如果是非 压缩 存储 将会 存储 0x0，并且占用一个字节。所有的整形类型（tinyint，smallint，int，bigint）对于0这个数值都是同等对待，数值由 压缩 行元数据进行描述并且不 存储 任何值
Smallint
让我们开始通过观察正常的未 压缩 的smallint数值， 对于 -2，-1，1，2这些值的 存储 ，0不会 存储 任何东西。注意，所有这些值会准确的存放在磁盘上，在这种情况下他们使用小字节序来 存储
- 2 = 0xFEFF - 1 = 0xFFFF 1 = 0x0100 2 = 0x0200
Little-Endian
从1，2 这两个值开始，他们很直接很简单的转换为decimal和你想要的实际数值。然而，-1有点不一样，显示0xFEFF 将他转换为decimal是65.535 --我们能 存储 的最大的无符号整形值是2个字节，
计算实际值依赖于所使用的整数溢出。看看下面的C#代码片段:
unchecked
{
Console.WriteLine( 0 + ( short ) 32767 );
Console.WriteLine( 0 + ( short ) 32768 );
Console.WriteLine( 0 + ( short ) 32769 );
// ...
Console.WriteLine( 0 + ( short ) 65534 );
Console.WriteLine( 0 + ( short ) 65535 );
}
输出如下：
32767 - 32768 - 32767 - 2 - 1
如果我们这样计算 0+有符号short的最大值，那么最大值就是有符号短整型 32767，很明显负数就是-32767，
然而，如果我们这样计算 0+32.768=32768，那么就会超出short的范围，我们将最高位翻转变成负数 -32768 却不会溢出。
因为这些数都是常数，编译器不允许溢出--除非我们将代码封装在uncheck ｛｝div里面
你可能曾经听过虚构的符号位。基本上它的最高位被用于指示一个数是正数还是负数。
从上面的例子应该很明显的显示符号位不是那么特别--通过查询这个符号位决定一个给定的数的符号。看一下当溢出的时候符号位会怎样
32767 = 0b0111111111111111 - 32768 = 0b1000000000000000 - 32767 = 0b1000000000000001
对于由于太大而引起溢出的数字，最高位[sign bit]需要进行设置。这不神奇,它只是用来引起溢出。
那么，我们有一些背景知识知道一个常规的非 压缩 integers 是如何 存储 的。现在看一下那些同样数值的smallint 是如何 存储 在行 压缩 表里的
- 2 = 0x7E - 1 = 0x7F 1 = 0x81 2 = 0x82
让我们尝试将这些值转换为decimal，我做如下转换
- 2 = 0x7E = - 128 + 126 - 1 = 0x7F = - 128 + 127 1 = 0x81 = - 128 + 129 2 = 0x82 = - 128 + 130
很明显，这些值会以另一种方式进行 存储 。最明显的不同是我们现在只使用一个字节--由于变成了可变长度 存储 。当我们解析这些值的时候，我们需要简单的看一下这些数字的字节 存储 。如果只使用一个字节，我们知道这表示0到255（对于tinyint来讲） 或者对于smallint 数值是 -128到127 。当smallint 存储 的那个值范围在-128到127 就会使用一个字节来 存储
如果我们使用相同的方法，我们明显会获得错误的结果 。1 0 + 129 诀窍是在本例中将 存储 的值作为无符号整数，然后最小值作为偏移量
而不是使用0来作为偏移，我们将使用有符号 的一个字节最小值-128 作为偏移
- 2 = 0x7E = - 128 + 126 - 1 = 0x7F = - 128 + 127 1 = 0x81 = - 128 + 129 2 = 0x82 = - 128 + 130
这意味着一旦我们超出有符号 的1个字节的范围 我们将需要用2个字节来 存储 ，对吗？
一个非常重要的区别是,非 压缩 值会永远使用小字节序来 存储 ，然而使用了行 压缩 的整数值却使用大字节序来 存储 ！
所以，他们不只使用不同的偏移值，而使用不同的字节序。但是最终的结果都是相同的，不过计算方式却有很大的不同
Int 和 bigint
一旦我找到字节序的规律和行 压缩 整型值的数值架构，int和bigint的实现就很简单了。和其他类型一样，他们也是可变长度的所以你有可能会碰到5字节长的bigint值和1字节长的int值。下面是SqlBigInt 类型的主要解析代码
switch (value.Length)
{
case 0 :
return 0 ;
case 1 :
return ( long )(- 128 + value[ 0 ]);
case 2 :
return ( long )(- 32768 + BitConverter.ToUInt16( new [] { value[ 1 ], value[ 0 ] }, 0 ));
case 3 :
return ( long )(- 8388608 + BitConverter.ToUInt32( new byte [] { value[ 2 ], value[ 1 ], value[ 0 ], 0 }, 0 ));
case 4 :
return ( long )(- 2147483648 + BitConverter.ToUInt32( new [] { value[ 3 ], value[ 2 ], value[ 1 ], value[ 0 ] }, 0 ));
case 5 :
return ( long )(- 549755813888 + BitConverter.ToInt64( new byte [] { value[ 4 ], value[ 3 ], value[ 2 ], value[ 1 ], value[ 0 ], 0 , 0 , 0 }, 0 ));
case 6 :
return ( long )(- 140737488355328 + BitConverter.ToInt64( new byte [] { value[ 5 ], value[ 4 ], value[ 3 ], value[ 2 ], value[ 1 ], value[ 0 ], 0 , 0 }, 0 ));
case 7 :
return ( long )(- 36028797018963968 + BitConverter.ToInt64( new byte [] { value[ 6 ], value[ 5 ], value[ 4 ], value[ 3 ], value[ 2 ], value[ 1 ], value[ 0 ], 0 }, 0 ));
case 8 :
return ( long )(- 9223372036854775808 + BitConverter.ToInt64( new [] { value[ 7 ], value[ 6 ], value[ 5 ], value[ 4 ], value[ 3 ], value[ 2 ], value[ 1 ], value[ 0 ] }, 0 ));
default :
throw new ArgumentException( " Invalid value length: " + value.Length);
}
可变长度的值是一个包含字节数据的字节数组 存储 在磁盘上。如果长度是0，没有东西 存储 因此我们知道他的值为0。
对于每一个剩余的有效长度，简单的使用最小的显示值作为偏移并且添加上 存储 的值
对于非 压缩 值我们可以使用BitConverter 类直接将输入值使用系统字节序转为期望值，对于大多数的英特尔和AMD系统，一般都是小字节序（意味着OrcaMDF 不会运行在一个大字节序的系统上）。然而，当 压缩 值使用大字节序进行 压缩 ，我必须重新映射输入的数组为小端字节 格式 ，并且在字节尾补上0 以便匹配short，int和long的大小
对于shorts和ints 我将无符号数值读取进来，因为这是我所感兴趣的。工作原理是将int 和uint强制转换为long值。我不能对long类型做同样的事情因为没有其他数据类型比long 更大了。对于long的最大值为9.223.372.036.854.775.807，在磁盘里实际 存储 为0xFFFFFFFFFFFFFFFF。解析有符号long型使用BitConverter得出的结果 -1 由于会导致溢出。由于额外的负数溢出这有可能会导致出错
- 9.223 . 372.036 . 854.775 . 808 + 0xFFFFFFFFFFFFFF => - 9.223 . 372.036 . 854.775 . 808 + - 1 = 9.223 . 372.036 . 854.775 . 807
结论
通常我有很多的有趣的尝试通过执行一个select语句去找出数值在磁盘上以哪一个字节结束。
这不会花很长的时间去实现，技术内幕的书只是作为引导，还有很多东西需要我们深入挖掘
第十三篇完
查看更多关于解剖SQLSERVER第十三篇Integers在行压缩和页压缩里的存储格的详细内容...