相关疑难解决方法(0)

作为 ETL 过程的一部分，我们将暂存中的行与报告数据库进行比较，以确定自上次加载数据以来是否有任何列实际发生了更改。

比较基于表的唯一键和所有其他列的某种散列。我们目前使用HASHBYTES该SHA2_256算法，并发现如果许多并发工作线程都在调用HASHBYTES.

在 96 核服务器上进行测试时，以每秒哈希数衡量的吞吐量不会增加超过 16 个并发线程。我通过将并发MAXDOP 8查询的数量从 1更改为12 来进行测试。测试MAXDOP 1显示了相同的可扩展性瓶颈。

作为一种解决方法，我想尝试 SQL CLR 解决方案。这是我试图说明要求的尝试：

• 该函数必须能够参与并行查询
• 函数必须是确定性的
• 该函数必须接受一个NVARCHAR或VARBINARY字符串的输入（所有相关列都连接在一起）
• 字符串的典型输入大小为 100 - 20000 个字符。20000 不是最大值
• 哈希冲突的几率应该大致等于或优于 MD5 算法。CHECKSUM对我们不起作用，因为冲突太多。
• 该函数必须在大型服务器上很好地扩展（每个线程的吞吐量不应随着线程数量的增加而显着降低）

对于 Application Reasons™，假设我无法保存报告表的哈希值。这是一个不支持触发器或计算列的 CCI（还有其他我不想讨论的问题）。

HASHBYTES使用 SQL CLR 函数进行模拟的可扩展方式是什么？我的目标可以表示为在大型服务器上每秒获得尽可能多的哈希值，因此性能也很重要。我对 CLR 很糟糕，所以我不知道如何做到这一点。如果它激励任何人回答，我计划尽快为这个问题添加赏金。下面是一个示例查询，它非常粗略地说明了用例：

DROP TABLE IF EXISTS #CHANGED_IDS;

SELECT stg.ID INTO #CHANGED_IDS
FROM (
    SELECT ID,
    CAST( HASHBYTES ('SHA2_256', 
        CAST(FK1 AS NVARCHAR(19)) + 
        CAST(FK2 AS NVARCHAR(19)) …