CHECKSUM_AGG仅适用于固定范围、确定语义的快照一致性比对，不能可靠检测业务意义的变更；因其基于XOR累积且忽略NULL、敏感行序与类型隐式转换，易误判或漏判。
CHECKSUM_AGG 不是用来“检测变更”的通用工具，它只适合做固定范围、确定语义的快照一致性比对；指望它发现“哪行改了”或“值是否业务上变化”，大概率会误判或漏判。
为什么 CHECKSUM_AGG 值变了 ≠ 数据有业务意义的变更
CHECKSUM_AGG 对输入值做 XOR 累积，结果是 int，天然丢失三类信息：
- 行顺序：两行互换位置，
CHECKSUM_AGG结果不变 - NULL 处理：直接忽略
NULL，但ISNULL(col, 0)和ISNULL(col, '')的CHECKSUM完全不同，而原生聚合不帮你选 - 重复敏感度低：比如
[100, 200, 100]和[200, 100, 100]可能产出相同校验和（小概率但存在）
更实际的例子：某字段从 'true' 改成 'TRUE'，CHECKSUM_AGG 会变——但它变不代表你关心这个变更；反过来，如果只是时间字段精度微调（如 DATETIME 转 DATETIME2(3)），原始值没动，但类型隐式转换后 CHECKSUM 就可能不同。
必须显式控制输入，否则 CHECKSUM_AGG 没法用
它不接受任意表达式，也不处理类型歧义。想让它输出稳定可比的结果，得手动封住所有变量：
- 所有字段必须显式
CAST或CONVERT到确定长度/精度类型，例如：CONVERT(VARCHAR(19), order_date, 120)、CAST(amount AS DECIMAL(18,2)) - 必须统一处理
NULL，不能依赖默认忽略，例如：ISNULL(CAST(status AS VARCHAR(10)), 'N/A') - 禁止用
CHECKSUM(*)：列顺序随ALTER TABLE变，下次就不可比 - 数据范围必须严格一致，加时间过滤或分区键限定，例如：
WHERE batch_id = @batch_id或order_date >= DATEADD(day, -7, GETDATE())
错误写法：SELECT CHECKSUM_AGG(CHECKSUM(Quantity, Status)) FROM orders —— Status 是 VARCHAR，没指定长度，隐式截断风险高；Quantity 若为 DECIMAL，直接传入会导致隐式转 INT 丢精度。
CHECKSUM_AGG vs COUNT(*) + SUM(*)：它补的是什么盲区
单纯比行数和求和，会完全漏掉这些真实问题：
- 两笔订单金额对调（
100 ↔ 200）：总和不变，但业务逻辑已错乱，CHECKSUM_AGG通常会变 - 删一行、加一行，金额相同但地址不同：
COUNT和SUM都不变，CHECKSUM_AGG很可能变化 - 字段被静默替换为语义等价但字节不同值（如
'Y'→'y'、'1'→1）：COUNT/SUM无感知，CHECKSUM_AGG会响应
但它不是银弹：它不告诉你哪一行、哪个字段变了，只告诉你“整体快照大概率不同”。真要定位变更，得配 ROWVERSION、变更数据捕获（CDC）或触发器日志。
一个可用的分组校验示例
校验每个用户最近 7 天订单摘要是否一致：
SELECT
user_id,
CHECKSUM_AGG(
CHECKSUM(
ISNULL(CAST(order_amount AS DECIMAL(18,2)), 0),
ISNULL(UPPER(LTRIM(RTRIM(order_status))), 'N/A'),
ISNULL(CONVERT(VARCHAR(19), order_date, 120), '')
)
) AS group_checksum
FROM orders
WHERE order_date >= DATEADD(day, -7, GETDATE())
GROUP BY user_id;
注意这里用了 UPPER 和 RTRIM 统一字符串形态，避免大小写/空格扰动；CONVERT(..., 120) 固定日期格式；所有 NULL 都显式兜底。每次运行都必须保证 WHERE 条件、字段列表、类型转换逻辑完全一致，否则比对无意义。
最常被忽略的一点：CHECKSUM_AGG 输出是 int，碰撞概率虽小但非零；若用于关键系统比对，建议额外加一层轻量校验（如 COUNT(*) + MIN(order_date)）交叉验证，而不是单靠一个数字下结论。
