因HASHBYTES在SQL Server 2014及更早版中输入限8000字节，2016+版虽放宽限制，但传入nvarchar(max)超4000字符（UTF-16下超8000字节）时仍静默截断，导致哈希仅反映前N字节；必须分块哈希再拼接，且需显式CAST为varbinary、处理NULL、按字节切分。
为什么直接用HASHBYTES校验大字段会失败
因为HASHBYTES在 SQL Server 2014 及更早版本中，输入参数最大只支持 8000 字节；即使 2016+ 版本放宽了限制，实际传入 varchar(max) 或 nvarchar(max) 时，仍可能被隐式截断——函数不会报错，但哈希值只反映前 N 字节，导致校验恒假或漏检。
-
HASHBYTES('SHA2_512', @large_text)中，若@large_text是nvarchar(max)且长度 > 4000 字符（UTF-16 下超 8000 字节），后半部分被静默丢弃 - 用
CONVERT(varbinary(max), @large_text)强转再传入，也不能绕过该限制——HASHBYTES内部仍按 8000 字节上限处理 - 错误现象：同一内容在不同环境哈希结果不一致；或 UPDATE 后校验突然通过，实则因字段变短刚好没越界
分块哈希 + 拼接是唯一可靠方案
对超长字段必须手动切片、逐块哈希、再组合。不能依赖单次调用，这是由 SQL Server 底层实现决定的硬约束。
- 用
SUBSTRING(@text, @start, 8000)分段，每次取 ≤8000 字节原始字节（注意nvarchar要按字节算，即最多 4000 字符） - 每块单独调用
HASHBYTES('SHA2_512', ...)，得到多个varbinary(64) - 将所有块哈希值拼成一个长二进制串（如
CONCAT(hash1, hash2, hash3)），再对其做最终哈希：HASHBYTES('SHA2_512', CONCAT(hash1, hash2, hash3)) - 避免用字符串拼接（如
CONVERT(varchar, hash1) + ...），易引入编码/排序规则干扰
如何让校验可索引且不拖慢查询
直接在 WHERE 中写 HASHBYTES('SHA2_512', large_column) = @expected 会导致全表扫描——函数作用于列，索引失效。
- 建计算列：
ALTER TABLE T ADD large_col_hash AS HASHBYTES('SHA2_512', LEFT(large_column, 8000)) PERSISTED（仅适用于 ≤8000 字节场景） - 对超长字段，计算列只能存「分块哈希后的最终哈希」，且必须
PERSISTED才能建索引 - 索引要建在计算列上：
CREATE INDEX IX_T_large_col_hash ON T(large_col_hash) - 查询时直接比对计算列：
WHERE large_col_hash = @precomputed_hash，走索引查找
容易被忽略的三个细节
这些点不报错，但会让哈希值跨环境不一致，导致校验在测试库通过、生产库失败。
- 输入类型必须显式统一：
HASHBYTES('SHA2_512', CAST(@text AS varbinary(8000)))，而非varchar或nvarchar——后者因排序规则和隐式转换导致字节序列不同 - NULL 值必须显式处理：
ISNULL(CAST(@text AS varbinary(8000)), 0x)，否则HASHBYTES(..., NULL)返回 NULL，参与CONCAT时整条结果变 NULL - 分块边界必须对齐字节，不能按字符切——尤其含 emoji 或中文时，
SUBSTRING(nvarchar, pos, len)的len指字符数，需换算为字节数再调整起始偏移
