checksum不适合精确数据比对，因其返回4字节整数，哈希碰撞概率高，无法保证唯一性；例如'aa'与'bb'可能产生相同值，且对null、大小写、字段顺序敏感，易误判数据未变更。
为什么CHECKSUM不适合做精确数据比对
SQL Server 的 CHECKSUM 函数返回的是 4 字节整数，存在高概率哈希碰撞——两个不同值可能生成相同 CHECKSUM 值。比如 CHECKSUM('Aa') 和 CHECKSUM('BB') 在某些版本中结果一致。它不保证唯一性，仅适合粗筛或内部排序场景，**不能用于判断“数据是否真的变了”**。
用CHECKSUM()做增量更新的典型写法及风险点
常见做法是给源表加计算列：ALTER TABLE dbo.OrderItems ADD row_hash AS CHECKSUM(OrderID, ProductID, Qty, Price)，再与目标表比对 row_hash 是否不同来触发更新。但要注意：
-
CHECKSUM对 NULL 处理敏感：多个字段含 NULL 时，CHECKSUM(NULL, 1)和CHECKSUM(1, NULL)结果相同，无法区分字段级空值位置差异 - 字符串大小写、尾部空格、Unicode 标记（如
N'abc'vs'abc'）可能被忽略，导致误判为“未变更” - 字段顺序调换会改变结果，但业务上可能语义等价（如交换两个描述字段）
更可靠的替代方案：HASHBYTES + 显式拼接
用 HASHBYTES('SHA2_256', ...) 替代 CHECKSUM，配合确定性拼接可大幅降低误判率。关键操作包括：
- 所有字段转成非 NULL 字符串并用分隔符连接，例如：
CONCAT(ISNULL(CAST(OrderID AS VARCHAR(10)), 'NULL'), '|', ISNULL(ProductID, 'NULL'), '|', ...) - 统一编码：对字符串字段显式用
CONVERT(VARCHAR(MAX), col COLLATE SQL_Latin1_General_CP1_CI_AS)避免排序规则影响哈希值 - 计算列定义需标记
PERSISTED才能建索引，否则每次查询都重算，性能差 - 示例表达式：
CONVERT(VARCHAR(64), HASHBYTES('SHA2_256', CONCAT(...)), 2)（返回小写十六进制字符串）
UPDATE时如何安全地基于哈希跳过未变动行
在 MERGE 或 UPDATE 中直接比较哈希值，但必须同步校验关键业务字段防漏——因为哈希仍非绝对可靠。推荐结构：
UPDATE t SET t.Price = s.Price, t.Qty = s.Qty FROM dbo.OrderItems t INNER JOIN staging_OrderItems s ON t.OrderID = s.OrderID WHERE t.row_hash != s.row_hash AND (t.Price != s.Price OR t.Qty != s.Qty OR t.Price IS NULL != s.Price IS NULL);
最后一行的显式字段比对是兜底逻辑，尤其防止 HASHBYTES 因隐式转换或 collation 差异导致的漏更新。实际生产中，如果字段多、变更频，建议把哈希比对和字段级比对拆成两阶段：先用哈希快速过滤 95% 未变记录，再对哈希不同的小批量做精确比对。
