sql server存储过程设可选参数最稳妥方式是为参数指定default null并置于参数列表末尾；where中须用@p is null而非@p = null判断；sql server无法原生区分“未传参”与“传null”，95%场景此方案已足够。
SQL Server 存储过程中怎么设可选参数
直接给参数加 DEFAULT NULL 是最常用也最稳妥的方式。SQL Server 允许在定义存储过程时为参数指定默认值，而 NULL 作为默认值语义清晰——既不干扰业务数据（多数业务字段本身允许 NULL），又便于后续逻辑区分“未传参”和“传了空值”。
注意：必须把带默认值的参数放在参数列表**末尾**，否则调用时若跳过中间参数，会报错 Procedure or function 'xxx' expects parameter '@p2', which was not supplied.。
示例：
CREATE PROCEDURE GetOrders
@CustomerId INT = NULL,
@Status VARCHAR(20) = NULL,
@MinAmount DECIMAL(18,2) = NULL
AS
BEGIN
SELECT * FROM Orders
WHERE (@CustomerId IS NULL OR CustomerId = @CustomerId)
AND (@Status IS NULL OR Status = @Status)
AND (@MinAmount IS NULL OR Amount >= @MinAmount)
END
WHERE 条件中如何安全判断 NULL 参数
别写 @param = NULL —— 这永远返回 UNKNOWN，条件失效。必须用 IS NULL 显式判断。
常见错误写法：WHERE CustomerId = @CustomerId（当 @CustomerId 为 NULL 时，整行被过滤掉）
正确逻辑是“参数为空则跳过该条件”，用 OR 拆解：
-
@param IS NULL→ 不加限制 -
@param IS NOT NULL→ 应用具体过滤
更简洁的等价写法（适用于相等匹配）：ISNULL(@param, ColumnName) = ColumnName，但要注意这可能阻止索引使用；推荐坚持用 OR + IS NULL 的显式写法，SQL Server 查询优化器对这种模式识别良好。
区分“没传参”和“传了 NULL”有实际意义吗
绝大多数场景下没有——因为 T-SQL 调用时不提供参数，和显式传 NULL，最终都落到同一个参数值上。SQL Server **无法原生区分二者**。
如果你真需要区分（比如想支持“显式清空某字段”语义），只能换方案：
- 用特殊哨兵值，如
-999表示“未传”，NULL表示“显式置空”（需业务层约定且文档清楚） - 拆成两个参数：
@CustomerId INT = NULL+@CustomerIdSpecified BIT = 0，靠后者控制逻辑分支 - 改用表值参数或 JSON 字符串传参，保留结构信息（适合复杂可选字段组合）
但代价是调用变重、可读性下降。95% 的分页查询、筛选报表类存储过程，用 = NULL 默认值 + IS NULL 判断已足够。
性能隐患：OR 条件会导致全表扫描？
不一定。SQL Server 2016 SP1+ 启用了“自适应查询处理”后，对这类参数化查询优化已有明显改进；即使旧版本，只要字段上有索引，且选择性好（比如 @CustomerId 对应的用户订单量远小于总订单数），执行计划通常仍能走索引查找（Index Seek）。
真正影响性能的是低选择性参数（如 @Status = 'Active' 占 90% 记录）或多个 OR 堆叠。此时可考虑：
- 用
OPTION (RECOMPILE)让每次执行都生成贴合当前参数的计划（适合参数变化大、执行频次不高的场景） - 拆成多个
IF分支，每个分支走专用查询（适合可选参数组合有限，比如最多 3 个布尔开关） - 避免在高并发 OLTP 存储过程中滥用
OR+NULL，优先用应用层拼接 SQL（如 ORM 动态查询）
最后提醒一句：测试时务必用 SET STATISTICS IO ON 和实际数据量验证执行计划，别只看语法对不对。
