一、SQLServer变量赋值的基本玩法
在SQLServer里给变量赋值，就像给小朋友分糖果一样简单直接。我们最常用的就是SET和SELECT这两种方式，虽然都能达到目的，但背后的门道可不少。
先看SET的典型用法：
DECLARE @UserName VARCHAR(50)
SET @UserName = '张三' -- 这是最直接的赋值方式
再看SELECT的赋值方式：
DECLARE @UserCount INT
SELECT @UserCount = COUNT(*) FROM Users -- 从查询结果中获取值
这两种方式在日常开发中都很常见，但很多开发者可能没注意到它们在性能和行为上的微妙差异。就像选择交通工具一样，虽然都能到达目的地，但自行车和跑车的体验完全不同。
二、SELECT赋值的特殊技能
SELECT赋值有个很实用的特性 - 它可以在一条语句中同时给多个变量赋值。这就像超市购物时一次性把东西都装进购物车，而不是一件件单独结账。
DECLARE @MaxID INT, @MinID INT, @AvgValue DECIMAL(10,2)
SELECT
@MaxID = MAX(UserID),
@MinID = MIN(UserID),
@AvgValue = AVG(Salary)
FROM Employees -- 一条语句搞定三个变量的赋值
这种批量赋值的特性在需要从同一数据源获取多个统计值时特别高效。想象一下，如果改用SET来实现，至少需要三条独立的查询语句，性能开销明显更大。
三、SET赋值的精确控制
虽然SELECT赋值很灵活，但SET在某些场景下反而更合适。SET就像精确的手术刀，适合需要明确控制的场合。
DECLARE @CurrentDate DATETIME
SET @CurrentDate = GETDATE() -- 简单的系统函数赋值
DECLARE @CalculationResult INT
SET @CalculationResult = 10 * 5 + 3 -- 直接计算表达式
当赋值来源是表达式或系统函数时，SET通常更直观。而且SET有个重要特性：如果赋值失败，它会明确报错，而SELECT可能会静默地赋NULL值。
DECLARE @NotFoundValue INT
SET @NotFoundValue = (SELECT TOP 1 ID FROM NonExistentTable) -- 明确报错
SELECT @NotFoundValue = (SELECT TOP 1 ID FROM NonExistentTable) -- 静默赋NULL
四、性能差异的真相大白
在性能方面，两者的差异主要取决于使用场景。通过实际测试可以发现：
- 简单赋值场景：
-- SET方式
DECLARE @i INT
SET @i = 1 -- 执行时间：0.0001秒
-- SELECT方式
DECLARE @j INT
SELECT @j = 1 -- 执行时间：0.0002秒
在这个最简单的场景下，SET略微快一点，但差异可以忽略不计。
- 复杂查询场景：
-- 使用SET
DECLARE @Count1 INT
SET @Count1 = (SELECT COUNT(*) FROM LargeTable WHERE ComplexCondition = 1) -- 执行时间：1.2秒
-- 使用SELECT
DECLARE @Count2 INT
SELECT @Count2 = COUNT(*) FROM LargeTable WHERE ComplexCondition = 1 -- 执行时间：1.1秒
当涉及复杂查询时，SELECT反而可能更快，因为它不需要像SET那样构建子查询。
五、实际应用中的黄金法则
根据多年经验，我总结了以下最佳实践：
- 简单赋值用SET：
DECLARE @StartDate DATETIME
SET @StartDate = '2023-01-01' -- 直接量赋值用SET更清晰
- 多变量赋值用SELECT：
DECLARE @Total INT, @Active INT, @Inactive INT
SELECT
@Total = COUNT(*),
@Active = SUM(CASE WHEN IsActive = 1 THEN 1 ELSE 0 END),
@Inactive = SUM(CASE WHEN IsActive = 0 THEN 1 ELSE 0 END)
FROM Users -- 一条查询搞定多个统计值
- 需要明确错误处理时用SET：
BEGIN TRY
DECLARE @Value INT
SET @Value = (SELECT NonNullableColumn FROM TableWhereRecordDoesNotExist)
-- 这里会抛出错误而不是静默赋NULL
END TRY
BEGIN CATCH
-- 错误处理逻辑
END CATCH
- 存储过程参数赋值优先用SET：
CREATE PROCEDURE UpdateUser
@UserID INT
AS
BEGIN
DECLARE @ModifiedDate DATETIME
SET @ModifiedDate = GETDATE() -- 参数初始化用SET更合适
-- 其他逻辑
END
六、那些年我们踩过的坑
在实际项目中，我遇到过不少因为赋值方式选择不当导致的问题：
- NULL值陷阱：
DECLARE @Result INT
SELECT @Result = SomeColumn FROM EmptyTable -- @Result保持原值(可能是NULL)
-- 很多开发者以为会赋0，实际保持原值
- 多行查询的意外：
DECLARE @Name VARCHAR(100)
SELECT @Name = UserName FROM Users -- 如果Users有多行，@Name会是最后一行值
-- 这通常不是开发者想要的结果
- 性能瓶颈：
-- 在循环中使用SET赋值
DECLARE @i INT = 1
WHILE @i <= 1000
BEGIN
SET @i = (SELECT MAX(ID) FROM LargeTable WHERE ID > @i) -- 每次循环都执行查询
-- 这样写性能极差
END
七、高级技巧：动态SQL中的赋值
在动态SQL中，赋值方式的选择更加重要：
DECLARE @TableName NVARCHAR(128) = 'Users'
DECLARE @SQL NVARCHAR(MAX)
DECLARE @Count INT
-- 正确做法：在动态SQL内部完成赋值
SET @SQL = N'SELECT @CountOUT = COUNT(*) FROM ' + QUOTENAME(@TableName)
EXEC sp_executesql @SQL,
N'@CountOUT INT OUTPUT',
@CountOUT = @Count OUTPUT -- 通过OUTPUT参数获取值
-- 错误示范：试图在外部获取值
SET @SQL = N'SELECT @Count = COUNT(*) FROM ' + QUOTENAME(@TableName)
-- 这样@Count不会被赋值，因为作用域不同
八、总结：如何做出明智选择
经过以上分析，我们可以得出以下结论：
- SET更适合：
- 简单直接的赋值
- 需要明确错误处理的场景
- 表达式和系统函数赋值
- 存储过程参数初始化
- SELECT更适合：
- 从查询结果中获取值
- 需要同时给多个变量赋值
- 复杂查询场景
- 需要保持变量原值而不是自动赋NULL的情况
- 通用建议：
- 始终初始化变量
- 考虑NULL值的影响
- 在循环中谨慎使用查询赋值
- 动态SQL中使用OUTPUT参数
记住，没有绝对的好坏之分，只有适合与否。就像选择工具一样，关键是了解每种方式的特性，然后根据具体场景做出最佳选择。
评论