小编Jam*_*all的帖子

我们有这种非常奇怪的行为，我们刚刚开始体验我们的 update intersect 语句。这些工作正常，但现在我们在列方面摄取了相当广泛的数据源，并逐渐减慢直至无限期挂起。

当我们以 20K 行（非常小）为一组添加数据时，下面的查询将变得越来越长，并且大约有 70K 行。没有使用索引，我们在摄取数据之前删除它们。

这是声明：

UPDATE Staging.[TdDailyPerformance]
SET [SYS_OPERATION] = 'U'
FROM (
    SELECT [HashCode]           
    FROM Staging.[TdDailyPerformance]
    INTERSECT
    SELECT [HashCode]
    FROM [IdMatch].[TdDailyPerformance]
) AS A

执行计划：

现在这个查询在我们服务器上的许多其他地方都有效，但不是在这里。有趣的是，无论是否INTERSECT返回行，查询都会永远挂起（我通过独立运行 intersect 来测试这一点 - 它花费的时间不到 2ms。）。

根据 SQL 似乎它不应该工作，但确实如此。如果HasCode在Staging表中已经存在IdMatch的表就更新[SYS_OPERATION]了的Staging表是“U”。我们在几个地方使用了这几个地方，它最近才开始在这个数据集上失败。

任何想法可能导致这种情况？

就我们所见，没有阻塞。交易的唯一等待类型CXPACKET是我对 QP 的期望。我已经查询sp_who2、查看了所有事务和活动监视器以识别块，但一无所获。我没有追过。

大多数情况下，我们的测试现在可以运行，因此它在挂起时有 0 行。但是我们已经验证它也挂起 1-100 行INTERSECT.

IdMatch有没有HashCodes存在的Staging，但是这两个表在杭的时间大约有70K行。所以要清楚，两个表都有大约 70K，但交叉点HashCode是 0 行。

我们已经用索引进行了测试。在我们遇到有问题的查询之前，我们的整体性能很差。索引只是碎片化得太快而无济于事。

表定义 …

我们有一个Truncate Table在 Snapshot 事务中运行的 proc 。这似乎导致了一个LOCK_M_S阻塞 sys 视图的锁sys.partitions。

有没有方便的解决方法？我喜欢不使用 truncate 发生的多余日志的效率，但不想锁定我的sys.partitions.

我很高兴应要求发布代码，但我很确定这是Truncate在 Snapshot 事务中的某种行为。我只是不知道。

基于我发现的一些有趣语法的快速问题。我有一个包含这些列的表：

ID INT,
DimBuyDetails_Id INT, 
WeekOfBuy INT,
Spots INT,
Retired BIT

如果我运行此查询，我将得到ROW_NUMBER()而不是COUNT()

SELECT *
    , COUNT(ID) OVER (
        PARTITION BY DimBuyDetails_Id, WeekOfBuy
        ORDER BY ID --<
) AS ct
FROM Core.FactBuysPerWeek

但是，如果我更改该ORDER BY条款，我会得到COUNT()

SELECT *
    , COUNT(ID) OVER (
        PARTITION BY DimBuyDetails_Id, WeekOfBuy
        ORDER BY DimBuyDetails_Id, WeekOfBuy --<Changed Order by here
) AS ct
FROM Core.FactBuysPerWeek

有谁知道是什么原因造成的？