SQL中字符串拼接不可用于动态生成WHERE条件，因CONCAT返回字符串值而非布尔表达式；安全做法是用“(@param IS NULL OR column = @param)”模式实现动态过滤，兼顾可读性、索引可用性与执行计划优化。
字符串拼接生成SQL在多数数据库里根本不可行
直接用 CONCAT 或 + 拼出带 WHERE 条件的字符串，再试图执行——这在标准 SQL（如 MySQL、PostgreSQL、SQL Server）中无法原生完成。SQL 不支持运行时动态解析字符串为可执行语句，除非调用存储过程中的执行函数（如 EXEC、EXECUTE IMMEDIATE），但那已脱离“纯查询”范畴，且带来注入风险与维护难题。
真正安全、可读、可优化的动态条件组合，靠的是「子查询 + 条件逻辑收敛」，而非字符串拼接。
- 拼接 SQL 是应用层（Python/Java/Node）该干的事，不是 SQL 自己该干的
- 数据库引擎无法对拼接后的字符串做执行计划缓存，每次都是硬解析
-
WHERE 1=1 AND CONCAT('status = ', @status)这类写法语法错误，CONCAT返回的是字符串值，不是布尔表达式
用 CASE 或布尔表达式让子查询“跳过”无效条件
核心思路：把每个可选条件转化为一个恒真或依赖参数的布尔子句，用 AND 连接，让数据库优化器自动剪枝。不需要 IF 或分支语法，靠 IS NULL 或 = '' 控制是否生效。
例如，要根据 @user_id、@status、@min_amount 动态过滤订单表：
SELECT * FROM orders WHERE (@user_id IS NULL OR user_id = @user_id) AND (@status = '' OR status = @status) AND (@min_amount IS NULL OR amount >= @min_amount);
- 参数为
NULL或空字符串时，对应条件恒真，等价于“不参与过滤” - 所有条件都在同一层
WHERE，无需嵌套，语义清晰，索引仍可能被使用（取决于具体值和统计信息） - 避免写成
AND (CASE WHEN @user_id IS NOT NULL THEN user_id = @user_id ELSE 1=1 END)—— 冗余且干扰优化器
当必须用子查询组合逻辑时，优先用 EXISTS 而非 IN
若需基于另一张表的动态结果做过滤（比如“查所有有未读消息的用户”），用 EXISTS 子查询比 IN 更可靠，尤其涉及 NULL 值时。
错误示范：WHERE user_id IN (SELECT user_id FROM messages WHERE is_read = 0) —— 若子查询返回 NULL，整个 IN 判定为 UNKNOWN，导致无结果返回。
正确写法：
SELECT * FROM users u WHERE EXISTS ( SELECT 1 FROM messages m WHERE m.user_id = u.id AND m.is_read = 0 );
-
EXISTS只关心是否存在匹配行，不关心值是否为NULL - 子查询可加更多条件（如时间范围、状态组合），天然支持多条件动态嵌套
- 数据库通常能将
EXISTS优化为半连接（semi-join），性能优于等价的JOIN+ 去重
嵌套查询中传参容易忽略的绑定时机问题
子查询里的参数（如 @start_date）是否能被外层访问，取决于数据库方言。MySQL 8.0+ 和 PostgreSQL 支持相关子查询中引用外层列，但不支持直接引用会话变量（如 @var）——变量值在子查询执行时可能已变更或未初始化。
- 在 MySQL 中，
SELECT * FROM t1 WHERE id IN (SELECT t2.id FROM t2 WHERE t2.time > @start_date)的@start_date是执行前一次性求值，没问题；但若在存储过程中循环赋值，就可能错绑 - 更稳妥的方式是把参数显式作为外层查询的列传入：用
(SELECT ... FROM (SELECT @start_date AS sd) AS p, ... WHERE time > p.sd) - PostgreSQL 推荐用
WITHCTE 预定义参数：WITH params AS (SELECT '2024-01-01'::date AS start_date) SELECT * FROM orders o JOIN params p ON o.created_at >= p.start_date;
参数作用域和求值时机，比语法结构更容易导致结果不符预期。
