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

原创 2006年06月10日 20:55:00

 

问题描述

       业务需求如下:

       有表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的机会

 

相关文章推荐

SQL Server-聚焦深入理解死锁以及避免死锁建议(三十三)

前言 终于进入死锁系列,前面也提到过我一直对隔离级别和死锁以及如何避免死锁等问题模棱两可,所以才鼓起了重新学习SQL Server系列的勇气,本节我们来讲讲SQL Server中的死锁,看到许多文章...

sql server中如何避免死锁

一、死锁的四个必要条件 1、互斥条件(Mutual exclusion):资源不能被共享,只能由一个进程使用。 2、请求与保持条件(Hold and wait):已经得到资源的进程可以再次申请...
  • whaxrl
  • whaxrl
  • 2014年03月27日 13:13
  • 446

SQL Server里面Deadlock 似乎无可避免

从SQL Server的Online Book里面描述Deadlock策略里面发现有下面的一种情况: Worker threads. A queued task waiting for an ava...
  • jamex
  • jamex
  • 2012年09月03日 15:29
  • 512

如何处理SQL Server死锁问题

Good articles to troubleshooting deadlock issue in SQL Server: deadlock is defined in the dictionar...

SQL SERVER 如何处理带字母的自增列--【叶子】

--需求说明: /* id col ---------- ---------- AB00001 a AB00002 b --当再插入数据的时候让id自动变成AB00003 ...

SQL Server在存储过程中编写事务处理代码的三种方法

SQL Server中数据库事务处理是相当有用的,鉴于很多SQL初学者编写的事务处理代码存往往存在漏洞,本文我们介绍了三种不同的方法,举例说明了如何在存储过程事务处理中编写正确的代码。希望能够对您有所...

SQL Server脚本编写和批处理

1.USE语句 用于设置当前的数据库 2.声明变量 DECLARE语句的语法格式如下: 可以一次声明一个变量,也可以一次声明多个变量。如果声明变量时,没有初始化变量,那么其值为NULL。设置变量的值...

SQL Server2000 配置发布及相关问题处理

配置SQL Server 2000复制和同步 环境 操作系统:Windows server 2003 Enterprise Edition Serveice Pack 2 数据库:MSSQ...
  • cozil
  • cozil
  • 2014年02月05日 12:43
  • 345

SQL Server 分布式事务处理(MS DTC)初探

SQL Server 分布式事务处理(MS DTC)初探 在联机文档中是这样描述MS DTC的: Microsoft 分布式事务处理协调器 (MS DTC) 是一个事务管理器,它允许客户端应用...

SQL SERVER 时间日期处理函数

Sql Server中的日期与时间函数 1. 当前系统日期、时间 select getdate() 2. dateadd 在向指定日期加上一段时间的基础上,返回新的 datetime ...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:避免在 SQL Server 中盲目地追求一句处理
举报原因:
原因补充:

(最多只允许输入30个字)