参数化查询失效是因为字符串拼接绕过了参数化机制，导致sql注入、执行计划污染和转义错误；正确做法是统一用参数占位符+sp_executesql动态传参，所有占位符须在参数定义中声明类型且非空参数必须传入。
SQL Server里用IF拼接WHERE条件时，为什么参数化查询会失效
直接字符串拼接 @sql = @sql + ' AND name = ''' + @name + '''' 看似简单，但会引发SQL注入、执行计划缓存污染、单引号转义错误（比如 @name = 'O''Connor'）三大问题。核心矛盾在于：动态拼接和参数化必须共存，不能二选一。
正确做法是统一用参数占位符，再把所有可能用到的参数都传进去，靠逻辑判断控制是否生效：
DECLARE @sql NVARCHAR(MAX) = 'SELECT * FROM users WHERE 1=1'
IF @name IS NOT NULL
SET @sql = @sql + ' AND name = @name_param'
IF @age_from IS NOT NULL
SET @sql = @sql + ' AND age >= @age_from_param'
-- 后续EXEC sp_executesql时，只传实际非NULL的参数变量名，但注意：所有@xxx_param都得在参数定义字符串里声明
关键点：
- 占位符名（
@name_param）和传入的变量名（@name）可以不同，但必须在sp_executesql的参数定义字符串里显式声明类型，例如N'@name_param VARCHAR(50), @age_from_param INT' - 即使某个条件没拼进去，对应参数仍要传进
sp_executesql——否则报错“必须声明标量变量” - 所有参数值必须原样传入，不要在拼SQL时做字符串处理
PostgreSQL中用CASE WHEN写动态WHERE，为什么总返回空结果
常见错误是把整个条件写成 CASE WHEN @status IS NOT NULL THEN status = @status ELSE TRUE END，这在PostgreSQL里语法不合法——WHERE子句不接受布尔表达式作为CASE的THEN分支结果。
正确写法是把条件拆成OR组合，利用短路逻辑绕过无效判断：
WHERE (@status IS NULL OR status = @status) AND (@category IS NULL OR category = @category) AND (COALESCE(@min_price, 0) = 0 OR price >= @min_price)
这种写法安全、可读、支持索引（只要字段上有索引且统计信息准确），但要注意：
-
COALESCE(@min_price, 0) = 0这种写法会阻止索引使用，应改用@min_price IS NULL OR price >= @min_price - 如果字段允许NULL，
@status = status无法匹配NULL行，需额外加OR (@status IS NULL AND status IS NULL) - PostgreSQL 12+ 支持
WHERE status = COALESCE(@status, status)，但语义等价于“不过滤”，性能不如显式OR
MySQL存储过程里用CONCAT拼WHERE，为什么EXPLAIN显示全表扫描
哪怕你写了 INDEX(status, category)，一旦WHERE里出现 status = IF(@status IS NULL, status, @status) 这类函数包裹字段的写法，MySQL就会放弃使用索引。
真正能走索引的动态条件写法只有两种：
- 显式OR结构：
WHERE (@status IS NULL OR status = @status) AND (@category IS NULL OR category = @category) - UNION ALL分路径（适合条件组合少、分支明确的场景）：
IF @status IS NOT NULL AND @category IS NOT NULL THEN SELECT * FROM orders WHERE status = @status AND category = @category; ELSEIF @status IS NOT NULL THEN SELECT * FROM orders WHERE status = @status; ELSE SELECT * FROM orders; END IF;
注意UNION ALL方式虽然执行计划干净，但维护成本高——每新增一个筛选字段，分支数指数级增长。
Oracle中绑定变量数量超限导致ORA-01000错误怎么办
当动态条件超过200个时，EXECUTE IMMEDIATE ... USING 会因绑定变量过多触发 ORA-01000: maximum open cursors exceeded。这不是SQL写错了，而是游标资源耗尽。
缓解策略优先级如下：
- 用
DBMS_SQL替代EXECUTE IMMEDIATE：它支持动态构建绑定变量数组，避免硬编码所有:b1, :b2... - 限制前端传入的最大条件数，在存储过程开头用
IF @cond_count > 50 THEN RAISE_APPLICATION_ERROR(-20001, 'Too many filters'); - 对长尾低频字段（如“备注包含关键词”）改用全文索引或单独异步查询，不塞进主WHERE
最隐蔽的坑是：Oracle对绑定变量名长度也有限制（30字符），@user_profile_custom_field_2024_value 这种命名容易截断，导致变量未绑定成功却无报错。
