sql server存储过程不支持变长参数，因语法硬限制要求参数定义时必须固定名称、顺序和类型；替代方案是用json/xml/udt传结构化条件，再通过sp_executesql动态构建安全、可缓存的查询。
SQL Server 存储过程本身不支持变长参数列表（如 ...args 或可变数量的 @p1, @p2, @p3）——这是语法硬限制，强行模拟容易引发 SQL 注入、类型错乱或维护灾难。
为什么不能直接用“变长参数”？
SQL Server 的 CREATE PROCEDURE 要求参数在定义时完全固定：名称、顺序、数据类型、是否 OUTPUT 都必须明确声明。运行时无法动态增减参数个数，也不支持类似 C# 的 params 或 Python 的 *args 机制。
常见误解是把多个可选参数（全设默认值）当成“变长”，但那只是“最多 N 个固定参数”，不是真正意义上的变长。
试图用字符串拼接 + EXEC() 模拟变长，会立刻掉进以下坑里：
- 无法利用参数化查询的安全性，
WHERE Name = '+ @name +'是典型注入入口 - 执行计划无法重用，每次拼接不同 SQL 就生成新计划，缓存污染严重
- 类型推导失败：传入
'2023'可能被当字符串而非DATE，隐式转换报错或索引失效
替代方案：用单个结构化参数承载多条件
真正可行且生产推荐的做法，是把“多个查询条件”打包成一个结构化输入，再在过程中解析。主流有三种落地方式：
-
JSON 字符串（SQL Server 2016+）：用
@filter NVARCHAR(MAX)接收 JSON，再用OPENJSON()展开为行集
示例：EXEC usp_SearchProducts @filter = N'{"category":"Electronics","minPrice":100,"inStock":true}' -
XML 参数（兼容老版本）：用
@filter XML，配合.nodes()和.value()提取字段
优势是强类型校验、Schema 支持，但语法略冗长 -
用户定义表类型（UDT）：提前建
CREATE TYPE FilterCondition AS TABLE (Key NVARCHAR(50), Value NVARCHAR(4000))，传入表变量
适合条件键值对明确、数量中等的场景，性能稳定，但调用端需构造表变量
无论哪种，核心逻辑都是：先解析，再动态拼接 WHERE 子句（用 sp_executesql + 参数化占位符），而不是拼接真实值。
动态 WHERE 拼接必须用 sp_executesql，不能用 EXEC()
即使你已用 JSON/XML/UDT 解析出条件集合，最终执行仍需动态 SQL —— 但必须走 sp_executesql，否则前功尽弃。
错误写法：SET @sql = @sql + ' AND Price > ' + CAST(@minPrice AS VARCHAR) → 值直插，无类型保护
正确写法：SET @sql = @sql + ' AND Price > @minPriceParam'，然后调用：EXEC sp_executesql @sql, N'@minPriceParam DECIMAL(18,2)', @minPriceParam = @minPrice
关键点：
- 所有变量都作为独立参数传入
sp_executesql，不拼进字符串 - 占位符名（如
@minPriceParam）和实际变量名可以不同，但类型必须严格匹配 - 避免在动态 SQL 中使用
CONCAT()或+拼接用户输入值
最容易被忽略的性能陷阱：参数嗅探 + 动态 SQL 组合
当存储过程内含动态 SQL，且首次执行时传入了极端参数（比如空字符串查全部），SQL Server 可能缓存一个全表扫描的低效计划，并复用于后续带索引字段的查询。
缓解手段有限但有效：
- 在
sp_executesql调用末尾加OPTION (RECOMPILE)（适用于执行频次不高、条件组合多的场景） - 对高频稳定条件，改用静态 SQL 分支（
IF @category IS NOT NULL ... ELSE IF @priceRange IS NOT NULL ...） - 禁用参数嗅探仅对主过程有效，对内部
sp_executesql无效，别白费劲加OPTIMIZE FOR UNKNOWN
真正的灵活查询，不在参数个数上做文章，而在如何安全、可控、可缓存地把意图从应用层传导到执行引擎——JSON + sp_executesql + 显式重编译，是当前最平衡的路径。
