checksum_agg是sql server中轻量级分组数据一致性校验方法，通过哈希整组值快速比对，但需处理null、固定列序、强制类型一致，仅适用于快速筛查而非精确验证。
用 CHECKSUM_AGG 快速比对分组数据是否一致
分组后想确认两套结果（比如测试环境 vs 生产环境、ETL 前后）是否完全一致，CHECKSUM_AGG 是 SQL Server 里最轻量的校验手段。它不逐行比，而是把整组值哈希成一个数字，适合快速兜底。
常见错误现象：CHECKSUM_AGG(CHECKSUM(*)) 返回 NULL —— 只要分组内任意一列含 NULL，CHECKSUM 就返回 NULL，进而让整个聚合为 NULL，导致误判“数据不同”。
- 必须显式处理
NULL：用ISNULL(col, '')或COALESCE(col, 'N/A')替换，且类型要一致（比如INT列不能直接ISNULL(col, '')，得转成字符串） - 列顺序敏感：
CHECKSUM('a','b')和CHECKSUM('b','a')结果不同，多列校验时务必固定顺序 - 不保证全局唯一：极小概率碰撞，仅用于快速筛查，不能替代主键或唯一约束校验
CHECKSUM_AGG 在 GROUP BY 中的实际写法
不是所有聚合场景都适合直接套用。重点在于：校验目标是“每组内部数据构成是否相同”，而不是“整张表哈希值”。所以得先按业务维度分组，再对组内明细做校验。
使用场景：核对订单明细表中，每个 order_id 下的商品列表是否在两次抽取中完全一致（含数量、SKU、价格）。
SELECT
order_id,
CHECKSUM_AGG(CHECKSUM(
ISNULL(CAST(item_id AS VARCHAR), ''),
ISNULL(CAST(quantity AS VARCHAR), ''),
ISNULL(CAST(price AS VARCHAR), '')
)) AS group_checksum
FROM order_items
GROUP BY order_id;
- 必须把参与校验的列全部传给内层
CHECKSUM，不能只传主键 -
CAST强制转字符串，避免数值类型隐式转换干扰哈希结果 - 如果列有
TEXT/NTEXT类型，CHECKSUM不支持，需先转VARCHAR(MAX)
为什么不用 HASHBYTES + STRING_AGG？
SQL Server 2017+ 确实能用 HASHBYTES('SHA2_256', STRING_AGG(...)) 更可靠，但实际用起来卡点明显：
-
STRING_AGG默认不保序，得加WITHIN GROUP (ORDER BY ...)，否则同组不同排序产生不同哈希值 - 字段含换行、逗号、单引号时，
STRING_AGG不自动转义，容易破坏结构，还得手动REPLACE -
HASHBYTES对输入长度敏感，超 8000 字节会截断（即使用了VARCHAR(MAX)），而CHECKSUM没这限制 - 性能上，
CHECKSUM_AGG是内置聚合函数，执行计划更稳定；STRING_AGG+HASHBYTES多一层字符串拼接，大数据量时 CPU 明显升高
校验结果不一致时，下一步查什么
CHECKSUM_AGG 只告诉你“哪几组有问题”，不告诉你“哪里不同”。这时候别急着重跑任务，先定位差异点：
- 挑一个校验值不同的
order_id，分别查两边数据，用EXCEPT或NOT EXISTS找出多出/缺失的行 - 注意浮点数：
float列用CHECKSUM容易因精度丢失导致误报，建议转成DECIMAL或四舍五入后再校验 - 时间字段：
DATETIME2(7)的微秒部分可能因写入时机不同而差 100ns，校验前统一CAST(dt AS DATETIME2(3)) - 大小写和空格：
VARCHAR列若排序规则是_CI（大小写不敏感），CHECKSUM却区分大小写，容易误报，校验前统一UPPER()
真正麻烦的永远不是算 checksum，而是校验值对不上时，怎么在没日志、没快照、没源系统权限的情况下，从两堆结果集里揪出那一个错位的字段。
