正确做法是显式判断参数是否为NULL，用WHERE (@param IS NULL OR column = @param)，避免直接写column = @param导致NULL时整行被过滤；但需注意该写法可能影响索引使用和执行计划效率。
SQL Server 存储过程中怎么处理 NULL 参数？
直接用 WHERE column = @param 会漏掉 @param 为 NULL 的情况——SQL 中 NULL = NULL 返回 UNKNOWN，不是 TRUE，所以整行被过滤掉。正确做法是显式判断参数是否为 NULL，再决定是否参与过滤。
常见写法是：WHERE (@param IS NULL OR column = @param)。但要注意：这种写法容易让 SQL Server 生成低效的执行计划（尤其在大表上），因为优化器难准确预估选择性。
- 如果参数大概率非空，且字段上有索引，可保留该写法，简洁直观
- 如果参数经常为
NULL或查询性能敏感，建议用动态 SQL 或条件拼接（见下节） -
ANSI_NULLS OFF不推荐——它已被弃用，且行为不可靠
MySQL 存储过程里怎么写可选 WHERE 条件？
MySQL 不支持 T-SQL 那种 OR 拆解写法的高效重写，而且它的查询优化器对 IFNULL() 或 COALESCE() 在 WHERE 中的使用更不友好。最稳妥的方式是拼接 SQL 字符串 + PREPARE/EXECUTE。
例如：CONCAT('SELECT * FROM users WHERE 1=1', IF(@name IS NOT NULL, CONCAT(' AND name = ''', @name, ''''), ''), ...)。注意必须手动转义单引号，否则注入风险极高。
- 务必用
REPLACE(@name, '''', '''''')（SQL Server）或REPLACE(@name, ''', '\'')（MySQL）做基础转义 - 优先考虑应用层拼接 SQL，而非在存储过程中拼——更易测试、审计和缓存
- MySQL 8.0+ 支持
JSON_CONTAINS()等函数，但不适用于常规可选参数场景
PostgreSQL 中用 COALESCE 实现可选参数靠谱吗？
不推荐直接用 WHERE column = COALESCE(@param, column)。表面上看它“等价于参数为空时不限制”，但实际会导致全表扫描——因为 COALESCE(@param, column) 是不可 SARGable 的表达式，索引失效。
真正可行的是用 IS NULL 判断分支，配合 UNION ALL 或 CASE 逻辑拆分，但更常用且清晰的是 WHERE ($1 IS NULL OR column = $1)（$1 是参数占位符）。PostgreSQL 的规划器对这种模式优化得不错，尤其是配合 ENABLE_SEQSCAN = OFF 测试时能观察到索引被选用。
- 确保参数类型与字段类型一致，否则隐式转换会让索引失效（比如传字符串给
INT字段） - 多个可选参数叠加时，避免写成
(@a IS NULL OR col_a = @a) AND (@b IS NULL OR col_b = @b)——可能触发差劲的嵌套循环 - 复杂场景建议用
plpgsql函数内部分支：IF $1 IS NOT NULL THEN ... END IF;
为什么动态 SQL 比静态 OR 写法更容易出错？
不是语法错，而是语义错：拼出来的 SQL 字符串漏空格、少括号、引号不闭合，运行时报错还好；更危险的是逻辑错误——比如把 AND 写成 OR，或者没加 WHERE 1=1 导致首条件前多出 AND，直接语法失败。
另一个隐形坑是参数绑定丢失：用字符串拼接时，@param 被当作文本插入，不再受参数化保护，极易 SQL 注入。哪怕只允许数字输入，也别手写 ' + CAST(@id AS VARCHAR) + ' 这种东西。
- SQL Server 推荐用
sp_executesql并传入参数列表，而不是EXEC(@sql) - PostgreSQL 必须用
EXECUTE ... USING，否则变量不会被安全绑定 - 所有数据库中，只要涉及用户输入，就绝不能跳过参数化——这是底线
可选参数看着简单，但每种数据库对 NULL 处理、索引利用、执行计划稳定性都有细微差异。最常被忽略的不是语法，而是类型匹配和执行计划是否真的用了索引——建议每次上线前用 EXPLAIN 或执行计划图确认。
