SQL Server中DECLARE变量必须紧随BEGIN之后、任何执行语句之前，是语法硬性限制；变量作用域限于当前BEGIN...END块，类型需匹配以避免截断或精度丢失，动态SQL中不能直接使用局部变量作为对象名。
SQL Server里DECLARE变量必须在BEGIN...END开头紧跟着写
SQL Server不支持在任意位置声明变量，DECLARE必须放在存储过程主体的最前面（即BEGIN之后、任何执行语句之前），否则会报错Incorrect syntax near 'DECLARE'。这不是风格问题，是语法硬性限制。
常见错误写法：
CREATE PROCEDURE sp_test AS<br>BEGIN<br> SELECT * FROM users;<br> DECLARE @id INT; -- ❌ 这里报错<br>END
正确顺序：
BEGIN<br> DECLARE @id INT;<br> DECLARE @name NVARCHAR(50);<br> SET @id = 123;<br> SELECT @name = name FROM users WHERE id = @id;<br>END
-
DECLARE语句可批量写，用分号或换行分隔，但不能穿插执行语句 - 同一作用域内不能重复
DECLARE同名变量，哪怕用IF分支包裹也不行 - 局部变量作用域仅限当前
BEGIN...END块，嵌套块需重新DECLARE
SET和SELECT赋值的区别不只是语法习惯
SET是标准SQL赋值方式，一次只能赋一个变量；SELECT是T-SQL扩展，支持一次给多个变量赋值，但行为更敏感——如果查询返回0行，变量保持原值（不置NULL）；返回多行则取最后一行值，且无警告。
示例对比：
DECLARE @val INT;<br>SET @val = NULL;<br>SELECT @val = status FROM orders WHERE id = -999; -- 返回0行 → @val仍为NULL<br>SELECT @val = status FROM orders; -- 返回多行 → @val = 最后一行status值
- 用
SET更安全：它要求右侧表达式必须返回单个标量值，否则直接报错Subquery returned more than 1 value - 用
SELECT做批量赋值时，务必确认查询结果集确定为单行，否则逻辑可能静默出错 - 从SQL Server 2022起，
SET @var = (subquery)也支持，但子查询仍必须单值，否则报错
变量类型要匹配实际数据，别依赖隐式转换
声明变量时指定的类型直接影响计算精度和截断行为。比如用DECLARE @price DECIMAL(5,2)存999.999，赋值时会被截断为999.99，且不报错。
容易踩的坑：
- 用
VARCHAR没指定长度（如DECLARE @x VARCHAR）→ 默认变成VARCHAR(1)，后续赋值全被截断 - 用
INT接AVG()结果 → 小数部分直接丢弃，应改用DECIMAL或FLOAT - 字符串拼接时混用
NVARCHAR和VARCHAR→ 可能触发隐式转换导致索引失效或性能下降
建议：优先用SELECT查询目标列的实际类型（查sys.columns或用sp_help），再按需声明变量类型。
局部变量不能用于动态SQL里的表名或列名
很多人误以为EXEC('SELECT * FROM ' + @table_name)能用变量传表名——不行。@table_name只是字符串值，SQL Server不会把它解析成对象名。这种场景必须用sp_executesql配合参数化，或拼接SQL字符串后EXEC，但后者有注入风险。
正确做法示例：
DECLARE @sql NVARCHAR(MAX), @table SYSNAME = 'users';<br>SET @sql = N'SELECT COUNT(*) FROM ' + QUOTENAME(@table);<br>EXEC sp_executesql @sql;
-
QUOTENAME()必须加，防止表名含空格或特殊字符导致语法错误 - 局部变量无法穿透到动态SQL内部作用域，所有需要传入的值都得拼进字符串或通过
sp_executesql的参数列表 - 不要用
SET @var = EXEC(...)想捕获动态SQL结果——语法不支持，得用临时表或输出参数
变量生命周期短、作用域窄、类型敏感，这些特性不是设计缺陷，而是为了控制执行边界。写多了就会发现，真正难的不是“怎么声明”，而是“在哪声明”和“为什么选这个类型”。
