动态SQL在存储过程中不能直接用变量拼接，因SQL Server编译时无法识别字符串变量为对象名；必须用EXEC()或sp_executesql执行，后者支持参数化、防注入且可复用执行计划。
动态SQL在存储过程中为什么不能直接用变量拼接
因为 SQL Server（以及其他主流数据库）在编译存储过程时就解析语句结构，@sql 这类字符串变量不会被当作可执行语句提前识别。直接写 SELECT * FROM @table_name 会报错 Must declare the table variable "@table_name"——它把 @table_name 当成了表变量，而不是字符串值。
真正生效的方式只有两种：用 EXEC() 或 sp_executesql。前者简单但无法参数化，后者支持参数传入、能复用执行计划，是更安全的选择。
用 sp_executesql 安全拼接 WHERE 条件
常见需求是根据输入参数动态加过滤条件，比如搜索用户时可选填姓名、部门、状态。硬写 IF...ELSE 分支容易失控，用动态 SQL 更灵活，但必须避免 SQL 注入。
- 所有用户输入的值，必须通过
sp_executesql的参数机制传入，**绝不拼进字符串** - 字段名、表名等非数据内容，如果来自可控配置（如枚举值或白名单），可用
QUOTENAME()包裹防注入；否则应拒绝运行 - 空值判断要显式处理，比如
@name IS NULL不能写成@name = NULL
示例：
DECLARE @sql NVARCHAR(MAX) = N'SELECT * FROM users WHERE 1=1';
DECLARE @params NVARCHAR(MAX) = N'@name NVARCHAR(50), @dept_id INT';
IF @name IS NOT NULL
SET @sql += N' AND name LIKE @name + ''%''';
IF @dept_id > 0
SET @sql += N' AND dept_id = @dept_id';
EXEC sp_executesql @sql, @params, @name = @name, @dept_id = @dept_id;拼接表名或列名时 QUOTENAME() 不是可选项
表名、列名不能走参数化，必须拼进 SQL 字符串。但直接拼 'SELECT * FROM ' + @table 极其危险——如果 @table 是 'users; DROP TABLE logs--'，就完了。
QUOTENAME() 会自动加方括号并转义内部字符，例如 QUOTENAME('user]s') 返回 [user]]s]，这是 SQL Server 唯一推荐的安全方式。
- 只对已知合法的标识符使用
QUOTENAME(@table_name)，不要用于任意用户输入 - 若需支持 schema，用
QUOTENAME(@schema) + '.' + QUOTENAME(@table) - 列名同理，
ORDER BY动态字段也得套一层QUOTENAME()
动态SQL执行失败时，PRINT @sql 比 RAISERROR 更快定位问题
报错信息常是“Incorrect syntax near ‘+’”这类泛泛提示，实际可能是引号没闭合、多了一个逗号、或者 NVARCHAR 长度不够截断了 SQL。这时候 PRINT @sql 输出完整语句，复制到 SSMS 里直接运行，错误位置一目了然。
-
@sql变量至少声明为NVARCHAR(MAX)，小容量类型（如NVARCHAR(200)）会在拼接中途静默截断 - 执行前加
IF LEN(@sql) > 4000 PRINT @sql，避免长 SQL 被 PRINT 截断（PRINT 单次最多输出 4000 字符） - 调试完务必删掉 PRINT，生产环境频繁输出会影响性能
真正麻烦的不是语法错，而是逻辑错：条件漏加、AND/OR 优先级混乱、NULL 处理不一致——这些不会报错，但结果不对，得靠测试数据反复比对。
