checksum_agg不适合实时监控，只适合离线快照比对；它基于xor运算，不敏感行序、忽略null、重复值可能抵消，仅能粗略指示分组整体是否变化，无法定位行级变更。
直接回答：CHECKSUM_AGG 不适合实时监控，只适合离线快照比对
它不是触发器或 CDC 那类变更捕获机制，不能告诉你“哪一行变了”“什么时候变的”“变成啥了”。它只在你主动执行时，返回一个 CHECKSUM_AGG 值；两次值不同，仅说明「这个分组的数据集整体大概率有变动」——但无法定位、无法归因、也无法排除误报。把它当“数据指纹”用可以，当“监控探针”用就会漏报或误告。
为什么 CHECKSUM_AGG 值不变 ≠ 数据没变
这是最容易踩的坑。XOR 运算的数学特性决定了它天然丢信息：
-
CHECKSUM_AGG对行顺序不敏感：A 行和 B 行互换位置，结果不变 - 自动跳过
NULL：CHECKSUM(NULL)被忽略，但CHECKSUM(ISNULL(col, 0))和CHECKSUM(ISNULL(col, ''))结果不同——而你没显式处理，就等于放任不确定性进入校验 - 重复值抵消风险：比如两行都是
100，XOR 后为 0；再加一行200，结果是 200；但如果删掉一个100、新增一个200，结果还是 200 —— 校验和没变，但数据已不同
怎么写才有点用：固定范围 + 显式类型 + NULL 统一
想让它在定期抽查中提供一点可信度，必须人工控制变量：
- 每次比对的数据范围必须完全一致，例如加上时间窗：
WHERE created_at >= DATEADD(day, -7, GETDATE()) - 所有字段必须显式转成确定类型并处理
NULL：ISNULL(CAST(price AS DECIMAL(18,2)), 0)、ISNULL(CONVERT(VARCHAR(10), order_date, 120), '1900-01-01') - 禁用
CHECKSUM(*)：列顺序随ALTER TABLE可能改变，必须手写全字段列表 - 避免浮点、datetime 直接参与：
CHECKSUM(GETDATE())每次都不同，毫无比对意义；应先格式化：CONVERT(VARCHAR(19), GETDATE(), 120)
示例（校验每日订单摘要一致性）：
SELECT
CAST(order_date AS DATE) AS dt,
CHECKSUM_AGG(
CHECKSUM(
ISNULL(CAST(total_amount AS DECIMAL(18,2)), 0),
ISNULL(status, 'UNKNOWN'),
ISNULL(customer_id, 0)
)
) AS daily_checksum
FROM orders
WHERE order_date >= DATEADD(day, -30, GETDATE())
GROUP BY CAST(order_date AS DATE);
CHECKSUM_AGG vs HASHBYTES：什么时候该换
如果你真需要强一致性校验（比如跨库比对、ETL 校验），CHECKSUM_AGG 的 int 范围（±21 亿）和碰撞概率就不可接受了：
-
HASHBYTES('MD5', ...)输出 128 位，碰撞概率极低，且支持CONVERT(VARCHAR, ..., 2)转成可读字符串 - 代价是性能下降约 3–5 倍（实测百万行聚合，
CHECKSUM_AGG耗时 120ms，HASHBYTES约 500ms） - 注意：
HASHBYTES不接受NULL，必须用ISNULL(col, '')包裹，否则整行被跳过
简单替换方式：
SELECT
user_id,
CONVERT(VARCHAR(32), HASHBYTES('MD5',
STRING_AGG(
ISNULL(CAST(amount AS VARCHAR), '') + '|' +
ISNULL(status, '') + '|' +
ISNULL(CONVERT(VARCHAR(10), created_at, 120), ''),
'|'
)
), 2) AS md5_checksum
FROM orders
GROUP BY user_id;
最常被忽略的一点：CHECKSUM_AGG 的值本身没有业务含义，它只是个中间标记。你必须自己存下历史快照、设计比对逻辑、定义“变化是否需告警”，SQL Server 不会替你做这些事。
