checksum_agg仅适用于粗粒度分组快照比对，不支持精确行级变更检测；因其基于xor运算，不保留行序、忽略null、对重复值敏感度低，须显式处理null、统一类型及固定排序逻辑，并配合时间戳存入校验表。
CHECKSUM_AGG 不是用来做精确比对的，它只适合快速筛查分组数据是否“大概没动”。如果你拿它当行级变更检测工具，结果会不可靠。
为什么 CHECKSUM_AGG 值不变 ≠ 数据没变
CHECKSUM_AGG 对分组内所有 CHECKSUM 值做 XOR 运算，天生丢三类信息：
- 行顺序：两行互换位置，结果可能完全一样
- NULL 处理：原生 CHECKSUM 遇到 NULL 直接忽略，但 ISNULL(col, 0) 和 ISNULL(col, '') 算出的值不同，而你没显式处理时就等于随机行为
- 重复值敏感度低：比如 CHECKSUM(100,200,100) 和 CHECKSUM(200,100,100) 在 XOR 下可能撞出相同整数（概率小但存在）
所以看到校验值没变，不能松口气；变了，也不代表业务上有意义的改动——比如只是把 'active' 改成 'ACTIVE'，它能捕获，但你未必要告警。
必须显式处理 NULL 和类型，否则结果无效
常见错误是直接写CHECKSUM(*) 或漏掉 NULL 转换，导致：
- 分组内任意一列含 NULL → 内层 CHECKSUM 返回 NULL → 外层 CHECKSUM_AGG 整个为 NULL
- datetime 直接传入 → 不同精度隐式转换，两次执行结果不一致
- float 字段参与 → 二进制表示浮动，哈希不稳定
正确做法：
- 所有字段用
ISNULL或COALESCE统一补值，且补值类型要和字段可转类型一致（例如INT列补'0'前得先CAST成字符串） - 时间类字段统一转成固定格式字符串：
CONVERT(VARCHAR(19), order_date, 120) - 数值类优先转
DECIMAL或字符串：CAST(amount AS DECIMAL(18,2)) - 列名必须显式列出，禁止用
*，避免表结构变更后列序错乱
GROUP BY 场景下怎么写才靠谱
目标是“每个分组内部构成是否一致”，不是整张表哈希。典型用法如核对每个order_id 下的明细是否在两次 ETL 后完全相同：
- 先按业务键 GROUP BY（如 order_id、user_id）
- 每组内对所有相关字段做 CHECKSUM，再套 CHECKSUM_AGG
- 示例：
SELECT order_id,
CHECKSUM_AGG(CHECKSUM(
ISNULL(CAST(item_id AS VARCHAR), ''),
ISNULL(CAST(quantity AS VARCHAR), ''),
ISNULL(CAST(price AS DECIMAL(18,2)), 0)
)) AS group_checksum
FROM order_items
GROUP BY order_id;
- 注意：如果字段含 TEXT 或 NTEXT，必须先转 VARCHAR(MAX)，否则 CHECKSUM 报错
和 HASHBYTES + STRING_AGG 比，选哪个
SQL Server 2017+ 可用HASHBYTES('SHA2_256', STRING_AGG(... WITHIN GROUP (ORDER BY ...)))，但实际踩坑多：
- STRING_AGG 默认不保序，不加 WITHIN GROUP 就等于每次结果随机
- 字段含逗号、换行、单引号时，不手动 REPLACE 就会破坏拼接结构
- 输入超 8000 字节会被截断（哪怕用了 VARCHAR(MAX)），而 CHECKSUM_AGG 没这限制
- 性能上，CHECKSUM_AGG 是原生聚合，执行计划稳定；字符串拼接在大数据量时 CPU 明显升高
真正需要精确比对（比如审计、回滚、CDC），别硬扛 CHECKSUM_AGG —— 它连行序都不保证，更别说字段级变更定位。该开 CHANGE TRACKING 就开，该建触发器就建，别指望一个 XOR 聚合函数扛起数据质量大旗。
