SQL Server中rowversion列的异常行为及可靠性疑问

你遇到的问题完全不是rowversion本身不可靠，而是rowversion与binary(8)类型的比较规则存在本质差异——这是很多开发者容易忽略的细节，踩坑很正常。

核心差异：rowversion vs binary(8)的比较逻辑 #

rowversion（旧称timestamp）虽然存储形式是8字节二进制，但它的比较逻辑是按照无符号64位整数的数值大小（对应SQL Server自动生成的递增顺序：每次修改行时，rowversion值自动递增，后生成的值一定比之前的大）。

而binary(8)的比较是逐字节的字典序：从左到右依次比较每个字节的ASCII值，只要某一个字节更大，整个binary值就被判定为更大，完全不考虑整体的数值意义。

你的测试案例解析 #

拿你提到的0x0000000070000000来说：

• 当作为rowversion类型时，它的无符号数值远小于你表中最小的rowversion值0x00000004355B68B7（因为后者的高位字节对应更大的整数），所以select * from MyTable where tStamp > @testRV判定为false，没有返回行。
• 当作为binary(8)类型时，逐字节比较到第四个字节时，0x00（测试值的第四个字节） < 0x04（表中tStamp的第四个字节），因此整个binary值比表中最小的tStamp小，tStamp > @testBin判定为true，返回所有行。

这就解释了为什么同一个二进制值，用不同类型变量比较会得到完全相反的结果。其他特殊值的异常表现，本质都是这两种比较规则的冲突导致的。

正确使用rowversion的建议 #

1. 统一类型：所有涉及rowversion比较的变量、存储过程参数，都必须使用rowversion（或timestamp，两者等价）类型，绝对不要用binary(8)。
2. 不要手动构造rowversion值：rowversion是SQL Server自动维护的递增标识，手动构造的值不符合它的生成逻辑，很容易触发异常的比较结果。
3. 传递参数时保持类型一致：存储过程之间传递rowversion参数时，必须保证参数类型都是rowversion，避免隐式转换导致比较规则切换。

只要遵循这些规则，rowversion的比较是完全可靠的，它的设计初衷就是用来高效检测行的修改状态，或者实现增量查询（比如where tStamp > @lastSyncTS）。

内容的提问来源于stack exchange，提问作者Andy D