动态拼接sql需防范注入与空值问题：sql server用isnull/coalesce处理null，mysql用ifnull/coalesce，postgresql用coalesce；where条件应动态追加而非硬塞；字符串值须用quotename或quote()转义；exec不安全，应优先用sp_executesql参数化用户值；对象名须白名单校验+转义；调试时print/select拼接sql并注意格式。
动态拼接 SQL 在存储过程中是常见需求，但直接用 + 或 CONCAT 拼字符串极易引发 SQL 注入、空值截断、引号逃逸等问题——关键不是“能不能拼”，而是“怎么安全地拼”。
拼接前必须处理 NULL 值
SQL Server 中任意字段或变量为 NULL，整段拼接结果就变成 NULL；MySQL 的 CONCAT 遇到 NULL 也会返回 NULL。不显式处理，执行时可能静默失败。
- SQL Server：统一用
ISNULL(@param, '')或COALESCE(@param, '') - MySQL：用
IFNULL(@param, '')或COALESCE(@param, '') - PostgreSQL：用
COALESCE(param, '')，注意不能用||直接连NULL
WHERE 条件动态追加的典型写法
用户传参不确定是否过滤某字段（比如可选的 @status），不能靠 AND (@status IS NULL OR status = @status) 硬塞进静态 SQL —— 这会让执行计划失效，索引容易被跳过。
- 正确做法：只在
@status非空时拼入AND status = 'xxx' - 避免手写单引号嵌套：用
QUOTENAME（SQL Server）或QUOTE()（MySQL）包裹字符串值 - 示例（SQL Server）：
SET @sql = @sql + ' AND status = ' + QUOTENAME(@status, '''');
EXEC 和 sp_executesql 的选择
EXEC(@sql) 最简但无法复用执行计划，且不能参数化输入值；sp_executesql 支持参数化，是安全拼接的核心防线。
- 所有用户可控值（如搜索关键词、ID 范围）必须走
@params参数传入，绝不可拼进字符串 - 表名、列名等对象名无法参数化，只能白名单校验 +
QUOTENAME（SQL Server）或反引号转义（MySQL） - 错误示范：
EXEC('SELECT * FROM ' + @table_name)→ 必须先验证@table_name是否在允许列表中
调试动态 SQL 的实际技巧
拼出来的 SQL 执行报错，但你根本看不到完整语句——这是最常卡住的地方。
- 开发阶段务必先
PRINT @sql（SQL Server）或SELECT @sql（MySQL）输出再手动执行验证 - 注意换行和缩进：用
CHAR(13)+CHAR(10)插入回车，让打印出的 SQL 可读 - 避免在生产环境留
PRINT，但调试时它是唯一能看清拼接结果的方式
真正难的不是把字符串连起来，而是判断哪部分能参数化、哪部分必须校验、哪部分连空格都得手动补全——漏掉一个引号、少一个空格、忽略一次 NULL，执行时就只是“查不到数据”或“语法错误”，不会告诉你哪里错了。
