CHECKSUM(col1,col2)可快速比行但需显式列名；CHECKSUM(*)高危因结构变更致校验失效；NULL和datetime/float等类型须统一处理；存储过程宜直接WHERE比对，禁用游标；CHECKSUM仅作差异初筛，须二次字段级确认。
直接用 CHECKSUM 比行，但别碰 CHECKSUM(*)
想快速判断两行是否“看起来一样”，CHECKSUM(col1, col2, col3) 是可行的，但必须显式列出字段。用 CHECKSUM(*) 是高危操作：一旦表结构变更（比如加个计算列、调整字段顺序），校验值就全乱了，连对比基准都失效。SQL Server 不保证 * 的列顺序稳定，尤其在有 ALTER TABLE 历史的生产表上。
CHECKSUM 的 NULL 和类型陷阱必须手动处理
原生 CHECKSUM(NULL) 返回 0，但 CHECKSUM(ISNULL(col, '')) 和 CHECKSUM(ISNULL(col, 0)) 结果完全不同——而你没写 ISNULL，它就按默认规则吞掉 NULL，导致源和目标比对时一边算 0、一边跳过，结果必然不等。datetime、float 这类类型也一样：直接传 order_date，不同会话的精度隐式转换可能让校验值漂移。
- 所有字段必须统一用
ISNULL(col, '')或ISNULL(CAST(col AS VARCHAR), '')处理 NULL - 时间字段优先转成确定格式：
CONVERT(VARCHAR(19), order_date, 120) - 金额类用
CAST(amount AS DECIMAL(18,2))，别信 float 或 money 的二进制表示
存储过程里比两行，别用游标逐行调 CHECKSUM
如果只是校验「当前行 vs 历史快照行」这种一对一场景，直接在 UPDATE/INSERT 触发器或存储过程里写 WHERE CHECKSUM(@col1, @col2) != CHECKSUM(t.col1, t.col2) 就够了。游标在这里纯属负优化：每行都调一次 CHECKSUM 函数，还带锁、占内存、拖慢整个事务。真正需要游标的，是那种必须调外部标量函数或记录每行失败详情的极端校验逻辑。
CHECKSUM 只能筛差异，不能当真相
哈希碰撞虽小概率，但存在；大小写变化（'Yes' → 'YES'）会被捕获，而业务上可能完全等价；日期格式不统一（'2026-09-17' vs '20260917'）会导致校验值不同，但数据语义没变。所以生产环境关键比对，必须分两步走：先用 CHECKSUM 快速筛出候选差异集，再对这些小结果集做字段级逐项比对（ISNULL(a.col, '') ISNULL(b.col, '')），否则你永远不知道那个“变了”的 checksum，到底是真数据错，还是格式抖动。
