现在的位置: 首页 > 综合 > 正文

避免在 SQL Server 中盲目地追求一句处理

2018年05月14日 ⁄ 综合 ⁄ 共 3172字 ⁄ 字号 评论关闭
问题描述
       业务需求如下:
       有表A和表B,这两个表结构一致,为不同的业务服务,现在要写一个存储过程,存储过程接受一个参数,当参数为0时,查询表A,参数为1时,查询表B
 
A、一般的处理方法
IF @Flag = 0
    SELECT * FROM dbo.A
ELSE IF @Flag = 1
    SELECT * FROM dbo.B
 
B、一句的处理方法
SELECT * FROM dbo.A
WHERE @Flag = 0
UNION ALL
SELECT * FROM dbo.B
WHERE @Flag = 1
 
分析
       从语句的简捷性来看,方法B具有技巧性,它们两者之间,究竟那一个更好呢?你可能会从性能上来评估,以决定到底用那一种。单纯从语句上来看,似乎两者的效率差不多,下面通过数据测试来反映结果似乎和想像的一样
 
建立测试环境(注,此测试环境是为几个主题服务的,因此结构看起来有些怪异)
USE tempdb
GO
 
SET NOCOUNT ON
--======================================
--创建测试环境
--======================================
RAISERROR('创建测试环境', 10, 1) WITH NOWAIT
-- Table A
CREATE TABLE [dbo].A(
    [TranNumber] [int] IDENTITY(1, 1) NOT NULL,
    [INVNO] [char](8) NOT NULL,
    [ITEM] [char](15) NULL DEFAULT (''),
    PRIMARY KEY([TranNumber])
)
 
CREATE INDEX [indexONinvno] ON [dbo].A([INVNO])
CREATE INDEX [indexOnitem] ON [dbo].A ([ITEM])
CREATE INDEX [indexONiteminnvo] ON [dbo].A([INVNO], [ITEM])
GO
 
-- Table B
CREATE TABLE [dbo].B(
    [ItemNumber] [char](15) NOT NULL DEFAULT (''),
    [CompanyCode] [char] (4) NOT NULL,
    [OwnerCompanyCode] [char](4) NULL,
    PRIMARY KEY([ItemNumber], [CompanyCode])
)
 
CREATE INDEX [ItemNumber] ON [dbo].B([ItemNumber])
CREATE INDEX [CompanyCode] ON [dbo].B([CompanyCode])
CREATE INDEX [OwnerCompanyCode] ON [dbo].B([OwnerCompanyCode])
GO
 
--======================================
--生成测试数据
--======================================
RAISERROR('生成测试数据', 10, 1) WITH NOWAIT
INSERT [dbo].A([INVNO], [ITEM])
SELECT LEFT(NEWID(), 8), RIGHT(NEWID(), 15)
FROM syscolumns A, syscolumns B
 
INSERT [dbo].B([ItemNumber], [CompanyCode], [OwnerCompanyCode])
SELECT RIGHT(NEWID(), 15), LEFT(NEWID(), 4), LEFT(NEWID(), 4)
FROM syscolumns A, syscolumns B
GO
 
进行性能测试
DECLARE @a int
SET @a = 1
 
DECLARE @t TABLE(
    id int IDENTITY,
    a int, b int)
DECLARE @dt datetime, @loop int, @id int
SET @loop = 0
WHILE @loop < 5
BEGIN
    SET @loop = @loop + 1
    RAISERROR('test %d', 10, 1, @loop) WITH NOWAIT
    SET @dt = GETDATE()
        SELECT [ITEM] FROM A
        WHERE @a = 0
            AND [ITEM] < 'A'
        UNION ALL
        SELECT [ItemNumber] FROM B
        WHERE @a = 1
            AND [ItemNumber] < 'A'
    INSERT @t(a) VALUES(DATEDIFF(ms, @dt, GETDATE()))
    SELECT @id = SCOPE_IDENTITY(), @dt = GETDATE()
        IF @a = 0
            SELECT [ITEM] FROM A
            WHERE [ITEM] < 'A'
        ELSE IF @a = 1
            SELECT [ItemNumber] FROM B
            WHERE [ItemNumber] < 'A'
    UPDATE @t SET b = DATEDIFF(ms, @dt, GETDATE())
    WHERE id = @id
END
SELECT * FROM @t
UNION ALL
SELECT NULL, SUM(a), SUM(b) FROM @t
 
性能测试结果
id a       b
--- ------- -------
1   3410   2063
2   1703   1656
3   1763   1656
4   1800   1793
5   1643   1856
NULL   10319 9024
 
从结果看,两者的性能差异很小,所以两者从性能上比较,可以视为没有差异
 
问题所在
虽然在性能上,两者没有什么差异,但另一个问题也许你从来没有考虑过,那就是对表的访问的问题,在方法A中,肯定只会访问到一个表;而在方法B中,情况还是如此吗?答案是否定的,方法B始终会扫描两个表。而这样的潜台词是,即使在我的查询中,只会用到A表,但如果B表被下了锁的话,整个查询就会被阻塞,而方法A不会
为了证明这个问题,我们再做下面的测试
 
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的机会

 

抱歉!评论已关闭.