至顶网›软件频道 ›不要在SQL Server中盲目地追求一句处理（5）

不要在SQL Server中盲目地追求一句处理（5）

扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条

在日常的学习和工作中，我们可以经常发现在处理SQL Server的时，很多人都会有一句出结果的习惯，但值得注意的是，不恰当的合并处理语句，往往会产生负面的性能。

作者：shuijing 来源：赛迪网 2007年8月25日

为了证明这个问题，我们再做下面的测试

BLOCK 的测试—为表A加锁： (查询窗口A)

BEGIN TRAN

    UPDATE A SET [ITEM] = RIGHT(NEWID(), 4)

    WHERE [ITEM] BETWEEN '9' AND 'A'

--ROLLBACK TRAN  -- 不回滚事务，让锁一直保持

BLOCK 的测试—测试查询方法A：(查询窗口B)

-- run query windows 2

DECLARE @a int

SET @a = 1
IF @a = 0

    SELECT [TranNumber] FROM A

    WHERE [ITEM] < 'A'

ELSE IF @a = 1

    SELECT [ItemNumber] FROM B

    WHERE [ItemNumber] < 'A'

BLOCK 的测试—测试查询方法B(查询窗口C)

-- run query windows 3

DECLARE @a int

SET @a = 1

 

SELECT [ITEM] FROM A

WHERE @a = 0

    AND [ITEM] < 'A'

UNION ALL

SELECT [ItemNumber] FROM B

WHERE @a = 1

    AND [ItemNumber] < 'A'

结果：

可以看到，查询窗口B中的查询会及时地完成，而查询窗口C的查询会一直等待，你可以通过执行存储过程 sp_who2，查看当前的BLOCK状况来确定查询窗口C的查询是否被查询窗口A的查询BLOCK住。

最后结论：

不要使用查询方法B，它看起来很不错，实际的结果即则是会增加被BLOCK的机会。

不要在SQL Server中盲目地追求一句处理 （5）

业界热点:

不要在SQL Server中盲目地追求一句处理（5）