PREPARE不支持参数化表名/字段名，因其仅接受值占位符；应通过白名单校验+正则过滤（如REGEXP '^[a-zA-Z0-9_]+$'）确保标识符安全，再拼接后使用?绑定值。
MySQL里用PREPARE执行动态表名或字段名时为什么总报错
因为PREPARE只接受完整的SQL字符串，但表名、列名不能用参数占位符?代替——那是给值用的，不是给标识符用的。硬拼字符串又容易被注入，尤其当来源不可信时。
实操建议：
- 如果表名/字段名来自可信配置（比如内部枚举），用字符串拼接+白名单校验，再传给
PREPARE - 用正则过滤掉非字母数字和下划线：
REGEXP '^[a-zA-Z0-9_]+$'，否则直接拒绝 - 避免在拼接中混入用户输入；哪怕只是ID后缀，也要单独用
?参数处理值部分 - 示例：
SET @sql = CONCAT('SELECT * FROM ', @table_name, ' WHERE id = ?');，然后EXECUTE stmt USING @id;
PostgreSQL中EXECUTE + USING怎么安全传参
PostgreSQL的EXECUTE支持动态语句，但只有USING后的值能参数化，表名、函数名、排序字段仍需拼接。关键在于：拼接部分必须隔离，值部分必须进USING。
常见错误现象：把整个SQL当字符串拼，结果USING没生效，或者类型不匹配报ERROR: there is no parameter $1。
实操建议：
-
EXECUTE里只放纯SQL结构，所有变量值统一挪到USING后面，顺序严格对应$1,$2… - 字段名/排序方向这类“半动态”内容，用
CASE或提前生成合法字符串，别塞进USING - 注意类型：传
text进USING没问题，但传integer字段名就会失败——字段名永远是标识符，不是值 - 示例：
EXECUTE 'SELECT * FROM users WHERE status = $1 ORDER BY ' || quote_ident(@sort_col) USING 'active';
SQL Server的sp_executesql为什么比EXEC更安全
因为sp_executesql明确分离了语句模板和参数值，SQL Server能复用执行计划，且参数自动转义；而EXEC直接拼字符串，等于裸奔。
使用场景：需要高频执行相似结构但不同条件的动态查询（比如后台搜索接口）。
实操建议：
- 所有用户可控的值，一律走
@param_name声明 +USING传入，绝不拼进SQL字符串 - 表名/列名仍需拼接，但必须用
QUOTENAME()包裹，防止注入（比如QUOTENAME(@table)返回[users]） - 别省略参数类型声明：
NVARCHAR(50)比NVARCHAR(MAX)更准，影响执行计划选择 - 示例：
EXEC sp_executesql N'SELECT * FROM ' + QUOTENAME(@tbl) + ' WHERE name = @n', N'@n NVARCHAR(50)', @n = @name;
动态SQL在ORM里要不要自己写
大多数情况不用。现代ORM（如Django ORM、SQLAlchemy、MyBatis）都内置了安全的动态构建能力，比如条件链式调用、Case表达式、Text片段嵌入，底层已处理好参数绑定和标识符转义。
容易踩的坑：
- 在ORM里又手动拼SQL字符串，等于绕过所有防护，还失去缓存和类型检查
- 误以为“ORM不支持动态排序”就手写
ORDER BY ?，结果报错——排序字段不能参数化，得用白名单+映射 - MyBatis的
<bind>和${}混用：前者安全，后者直接替换，必须加OGNL校验 - 真要突破ORM限制时，优先选
text()+ 绑定参数，而不是execute_raw()拼整条SQL
动态SQL最难的从来不是语法，而是界定哪些部分必须拼、哪些必须参数化，以及拼之前有没有做足够窄的白名单或转义。一不留神，quote_ident忘了调，或者QUOTENAME写成QUOTENAME(@col, ']')漏了左括号，查半天才发现是语法错误而非逻辑问题。
