在日常的学习和工作中，我们可以经常发现在处理SQL Server的时，很多人都会有一句出结果的习惯，但值得注意的是，不恰当的合并处理语句，往往会产生负面的性能，本篇针对使用 UNION ALL 代替 IF 语句的合并处理做出一个简单的事例，用来说明这种方法会所带来的负面结果。 示例： 表A和表B，这两个表结构一致，为不同的业务服务，现在写一个存储过程，存储过程接受一个参数，当参数为0时，查询表A，参数为1时，查询表B。 1:一般处理方法: IF @Flag = 0 SELECT * FROM dbo.AELSE IF @Flag = 1 SELECT * FROM dbo.B | 2、一句处理方法: SELECT * FROM dbo.AWHERE @Flag = 0UNION ALLSELECT * FROM dbo.BWHERE @Flag = 1 | 细化分析： 从语句的简捷性来看，方法b具有技巧性，它们两者之间，究竟那一个更好呢？你可能会从性能上来评估，以决定到底用那一种。单纯从语句上来看，似乎两者的效率差不多，下面通过数据测试来反映结果似乎和想像的一样。 建立测试环境：（注，此测试环境主要是为几个主题服务，因此结构看起来稍有差异） USE tempdbGO SET NOCOUNT ON--======================================--创建测试环境--======================================RAISERROR('创建测试环境', 10, 1) WITH NOWAIT-- Table ACREATE 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 BCREATE 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 NOWAITINSERT [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 BGO | 进行性能测试： DECLARE @a intSET @a = 1 DECLARE @t TABLE( id int IDENTITY, a int, b int)DECLARE @dt datetime, @loop int, @id intSET @loop = 0WHILE @loop < 5BEGIN 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 = @idENDSELECT * FROM @tUNION ALLSELECT NULL, SUM(a), SUM(b) FROM @t | 性能测试结果： id a b--- ------- -------1 3410 20632 1703 16563 1763 16564 1800 17935 1643 1856NULL 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 2DECLARE @a intSET @a = 1IF @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 3DECLARE @a intSET @a = 1 SELECT [ITEM] FROM AWHERE @a = 0 AND [ITEM] < 'A'UNION ALLSELECT [ItemNumber] FROM BWHERE @a = 1 AND [ItemNumber] < 'A' | 结果： 可以看到，查询窗口B中的查询会及时地完成，而查询窗口C的查询会一直等待，你可以通过执行存储过程 sp_who2，查看当前的BLOCK状况来确定查询窗口C的查询是否被查询窗口A的查询BLOCK住。 最后结论： 不要使用查询方法B，它看起来很不错，实际的结果即则是会增加被BLOCK的机会。 |
