SELECT一次赋多变量更快，因其单次集合操作提取多个值；SET每次仅赋一变量且重复查询，尤其右侧为子查询时效率更低。
SQL Server里用SELECT一次赋多个变量，为什么比SET更快
因为SELECT是集合操作，单次执行就能从结果集中提取多个值；而SET每次只能赋一个变量，每调用一次都触发一次标量求值。尤其当右侧是子查询时，SET @a = (SELECT ...)和SET @b = (SELECT ...)会分别执行两次查询；SELECT @a = col1, @b = col2 FROM ...只查一次表。
但前提是：查询必须返回且仅返回一行。多行会静默截断（只取第一行），零行会让变量保持原值（不是NULL）——这点极易被忽略。
- 必须确保
WHERE条件能精确命中单行，比如主键或唯一索引字段 - 如果不确定是否单行，优先加
TOP 1并配ORDER BY明确语义 - 变量未初始化时，用
SELECT赋值前它的值是NULL；若查询无结果，它仍为NULL；而SET在无结果时会设为NULL - 避免在
SELECT赋值中混用列和表达式，尤其是含聚合或窗口函数的，容易触发意外执行计划
DECLARE + SELECT批量赋值的典型写法与陷阱
常见错误是把DECLARE和SELECT拆成两步，中间穿插其他语句，导致变量作用域或执行顺序出问题。正确姿势是一气呵成：
DECLARE @total BIGINT, @count INT, @avg DECIMAL(10,2); SELECT @total = SUM(amount), @count = COUNT(*), @avg = AVG(amount) FROM orders WHERE status = 'shipped' AND order_date >= '2026-01-01';
注意三点：
-
@total类型必须兼容SUM()结果——这里用BIGINT防溢出，别用INT - 所有变量必须在同一
SELECT中赋值，不能拆成两个SELECT，否则失去“单次查询”优势 - 如果
WHERE条件可能无匹配，且业务要求变量为0而非NULL，得显式用ISNULL(SUM(...), 0)
什么时候不该用SELECT批量赋值
当右侧逻辑涉及多表JOIN、复杂过滤或需要强制按顺序求值时，SELECT反而危险。优化器可能重排计算顺序，导致依赖关系错乱。
例如这个写法是错的：
SELECT @start = MIN(created), @end = MAX(created) FROM events WHERE user_id = @uid;
表面看没问题，但如果events表没有user_id索引，或统计信息过期，优化器可能先算@end再算@start，而你后续代码又假设@start已就绪——这种隐式依赖极难调试。
- 涉及聚合+分组时，必须加
GROUP BY，否则语法报错；但加了GROUP BY后就不再是“单行”语义 - 变量之间有强先后依赖（如
@next_id = @current_id + 1），必须用SET逐条赋值 - 跨批次逻辑（比如先查A再根据A结果查B），硬塞进一个
SELECT会写出难以维护的嵌套子查询
替代方案：用CTE或临时表提前固化中间结果
当批量赋值变得复杂或不可靠时，不如把计算结果先存下来。比起反复查同一张表，用#temp或CTE更可控。
比如要同时拿到用户总订单数、最近下单时间、平均金额：
WITH user_stats AS (
SELECT
COUNT(*) AS cnt,
MAX(order_date) AS last_order,
AVG(amount) AS avg_amt
FROM orders
WHERE user_id = @uid
)
SELECT @count = cnt, @last = last_order, @avg = avg_amt
FROM user_stats;
这样既保留单次查询优势，又隔离了计算逻辑，还能让执行计划更稳定。关键是：user_stats的统计信息由优化器准确评估，不会像变量那样“看不见”。
真正难的不是怎么写快，而是判断哪部分该缓存、哪部分该重算——变量只是容器，决定它有没有价值的，是你对数据流动路径的理解。
