SQL Server存储过程应使用ISNULL()或COALESCE()在参数首次使用前兜底处理NULL，因显式传NULL不会触发默认值；WHERE中避免NULL导致逻辑错误和索引失效，需结合标志变量或动态SQL确保查询正确与高效。
SQL Server 存储过程中如何安全处理 NULL 输入参数
直接给结论：用 ISNULL() 或 COALESCE() 在参数首次被使用前做兜底，别依赖客户端传默认值。SQL Server 不会自动把未传参的 NULL 替换成定义时的默认值（比如 @name VARCHAR(50) = 'unknown'），那个默认值只在调用时完全省略该参数才生效；一旦显式传了 NULL，就真按 NULL 走。
常见错误现象：WHERE name = @name 遇到 @name 是 NULL 时查不到任何数据（因为 NULL = NULL 返回 UNKNOWN）；或插入语句因 NULL 违反 NOT NULL 约束报错。
- 所有入参都应视为「可能为
NULL」，哪怕声明了默认值 - 优先用
ISNULL(@name, 'unknown')—— 性能略好、语义明确，但仅限 SQL Server - 跨平台兼容场景用
COALESCE(@name, 'unknown', '')，支持多参数 fallback，且符合 ANSI 标准 - 避免在
WHERE条件里直接写@name IS NULL OR name = @name，会导致索引失效；改用name = ISNULL(@name, name)或动态拼接（谨慎）
MySQL 存储过程里怎么让空字符串和 NULL 都走默认逻辑
MySQL 对空字符串 '' 和 NULL 区分严格，而业务常把二者等同看待。不能只靠 IF p_name IS NULL THEN ...，得合并判断。
使用场景：前端传空字符串表示“不筛选”，后端却当成有效值插入导致脏数据；或更新语句把 '' 写进 NOT NULL 字段失败。
- 统一清洗：用
IF TRIM(IFNULL(p_name, '')) = '' THEN SET p_name = 'default'; END IF; -
IFNULL()处理NULL，TRIM()干掉纯空格，再判空，三步缺一不可 - 注意
CONCAT()遇到NULL整体返回NULL，拼接前务必先用IFNULL()转换 - 性能影响小，但别在循环体内反复调用这些函数，提取到变量里复用
PostgreSQL 中用 COALESCE 做参数容错的几个坑
PostgreSQL 的 COALESCE() 行为看似简单，但类型隐式转换容易翻车——比如把 TEXT 默认值和 INTEGER 参数混用，会报 function coalesce(integer, text) does not exist。
错误现象：COALESCE(user_id, '0') 报错；或 COALESCE(created_at, '1970-01-01') 返回字符串而非 TIMESTAMP，后续计算出错。
- 所有分支必须显式转成同一类型：
COALESCE(user_id, 0::INTEGER)或COALESCE(created_at, '1970-01-01'::TIMESTAMP) - 别依赖 PostgreSQL 的自动类型推导，它有时选错主类型（尤其涉及
NUMERIC和FLOAT） - 在函数定义里加
DEFAULT值（如IN p_status TEXT DEFAULT 'active'）仅对调用时省略参数有效，不防NULL - 触发器中用
COALESCE(NEW.field, OLD.field)很常见，但注意OLD在 INSERT 触发器里是NULL，需额外判断
存储过程里默认值覆盖后，怎么避免 WHERE 条件失效
最隐蔽的问题：参数被 ISNULL() 或 COALESCE() 覆盖后，本意是“不筛选”，结果写成 WHERE status = @status，变成强制匹配默认值，反而筛掉了其他数据。
本质是逻辑没区分「用户有意筛选」和「用户没提供筛选条件」。不能只靠值替换，得保留原始是否为空的状态。
- 加一个标志变量：
DECLARE @is_status_specified BIT = CASE WHEN @status IS NULL THEN 0 ELSE 1 END; - WHERE 写成：
AND (@is_status_specified = 0 OR status = @status)，让优化器仍有机会走索引 - 如果参数太多，考虑用动态 SQL（但必须用
sp_executesql+ 参数化，禁用字符串拼接防止注入） - 千万别用
WHERE ISNULL(@status, status) = status，看起来巧，实际无法利用索引，大数据量时慢到崩溃
复杂点在于：你得同时管理「参数值」和「参数是否被设置」两个状态，少一步，查询就可能错漏或变慢。这点很容易被忽略，尤其当开发只关注功能通过，不看执行计划。
