动态 SQL 的风险并非源于某个具体函数，而是运行时拼接让输入变成了语法成分。攻击者只需调整引号闭合方式，就能改变条件逻辑。要理解 PREPARE 与参数绑定的价值，需要先看清拼接语句的执行路径。
一、动态 SQL 的注入风险来自语法结构被篡改
动态 SQL 通常指根据业务条件在运行时拼接生成的 SQL 语句。例如按用户输入的用户名和状态查询用户列表，最简单的写法是把变量直接嵌入字符串。假设用户名字段收到 admin' OR '1'='1 这样的输入，SQL 变为 SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND status = 1。数据库执行时看到的是两个永远成立的条件，结果集就从单条扩展为整表。
这种攻击的根因不是引号或等号本身，而是 SQL 在解析前拼接，用户输入有机会改变关键字、操作符和逻辑组合。注释符 -- 可以截断后续条件，分号可以堆叠语句，UNION 可以跨表读取。只要拼接点足够多，防火墙和黑名单过滤都难以穷举。因此防御要回归到执行机制，让参数无法参与语法编译。
二、PREPARE 与参数绑定的工作机制
PREPARE 的核心是把 SQL 处理拆成解析和执行两个阶段。数据库先接收带有占位符的模板，例如 SELECT id, username FROM users WHERE id = ?，解析器生成语法树和关系代数计划。此时 id 后面的 ? 被明确标记为参数位置，而不是常量。
当 EXECUTE 阶段传入实际参数时，数据库使用已经固定的语法树，只把参数值作为叶子节点代入。这意味着无论参数内容是 OR '1'='1 还是 DROP TABLE，它都只被当作一个字符串或数字，不会触发语法规则。参数与语法树之间没有字符串层面的合并，注入所需的改变语法条件自然不成立。
不同数据库的占位符不同，但思想一致：MySQL 使用 ?，PostgreSQL 使用 $1、$2，SQL Server 的参数化查询常用 @name。驱动层（如 JDBC 的 PreparedStatement、PHP 的 PDO）也基于同一套客户端或服务端预处理协议。
三、主流数据库中的 PREPARE 与参数绑定写法
MySQL 支持服务端 PREPARE 语句，适合在存储过程或脚本中动态执行参数化语句。下面例子按用户 ID 查询，ID 值通过变量传入，不会直接拼进 SQL。
PREPARE stmt FROM 'SELECT id, username, email FROM users WHERE id = ?'; SET @user_id = 100; EXECUTE stmt USING @user_id; DEALLOCATE PREPARE stmt;
PostgreSQL 的 PREPARE 可以为语句命名并声明参数类型，之后多次 EXECUTE。参数以 $n 形式引用，位置清晰。
PREPARE find_user(int) AS SELECT id, username, email FROM users WHERE id = $1; EXECUTE find_user(100); DEALLOCATE find_user;
SQL Server 不常用独立 PREPARE，而是通过 sp_executesql 执行参数化 SQL。该存储过程接收 Unicode 语句文本和参数定义，既能防注入又能复用执行计划。
EXEC sp_executesql N'SELECT id, username, email FROM users WHERE id = @user_id', N'@user_id INT', @user_id = 100;
这些写法虽然语法不同，但都避免了字符串拼接。在真实应用中，更多开发者会使用驱动层预处理，下一节展示 Java JDBC 的完整示例。
四、参数绑定覆盖不到的场景与白名单策略
参数绑定只能用于值位置，不能用于表名、字段名、排序方向、LIMIT 数量等语法对象。因为语法树在 PREPARE 时已固定，标识符不能作为参数传入。若试图把表名写成占位符，数据库会报语法错误，而不是接受数据。
这类场景必须用程序控制。做法是维护白名单映射，把前端传入的排序字段转换为固定列名。例如只允许 create_time 和 update_time，排序方向只能是 ASC 或 DESC。下面代码通过 Map 校验，非法值直接回退到默认排序，避免拼接。
Map<String, String> orderColumnMap = new HashMap<>();
orderColumnMap.put("create", "create_time");
orderColumnMap.put("update", "update_time");
String orderColumn = orderColumnMap.getOrDefault(inputOrder, "create_time");
String direction = "DESC".equalsIgnoreCase(inputDir) ? "DESC" : "ASC";
String sql = "SELECT * FROM users WHERE status = ? ORDER BY " + orderColumn + " " + direction;
PreparedStatement ps = conn.prepareStatement(sql);
ps.setInt(1, 1);
ResultSet rs = ps.executeQuery();
上面代码块中的 Map<String, String> 在页面中会正确显示为尖括号形式。这里虽然 SQL 语句使用了字符串拼接，但拼接内容完全来自白名单变量，不包含用户原始输入，因此风险可控。状态字段仍然使用占位符绑定。
对于 LIMIT 和 IN 列表，参数绑定的支持程度不同。MySQL 5.7 及以前对 LIMIT 参数化支持有限，PostgreSQL 可以绑定但需要类型转换。IN 列表可以拆分为多个占位符，或者使用表值参数，不要直接拼接逗号分隔字符串。
五、应用层预处理与性能收益
JDBC 的 PreparedStatement 是应用层最常用的参数绑定方式。连接池会维护预处理语句缓存，数据库端也可以复用执行计划。下面代码从用户输入读取邮箱，全程不拼接，即使输入包含引号或注释符号也只会作为字符串比对。
String sql = "SELECT id, username, status FROM users WHERE email = ? AND status = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
ps.setString(1, userEmail);
ps.setInt(2, 1);
try (ResultSet rs = ps.executeQuery()) {
while (rs.next()) {
System.out.println(rs.getInt("id"));
}
}
}
参数绑定除了安全，还能显著降低数据库硬解析开销。对于高频查询，占位符模板固定，数据库可以命中计划缓存，避免每次都重新分析语法、检查权限和选择索引。Oracle、SQL Server 对字面量 SQL 的缓存能力有限，参数化后执行计划更稳定，这也是性能优化中常被忽略的收益。
需要提醒的是，某些驱动可能默认使用客户端模拟预处理，而不是真正的服务端预处理。PHP PDO 的 ATTR_EMULATE_PREPARES 选项就是一个典型例子。开启模拟时，驱动在客户端做转义和替换，虽然也能防注入，但执行计划缓存效果不如服务端预处理，应根据数据库支持情况关闭模拟。
总之，PREPARE 与参数绑定是防御 SQL 注入的第一道也是最重要的一道防线。它不依赖黑名单、不依赖输入长度限制，而是从执行机制上切断了输入影响语法的通道。对于少数必须动态指定标识符的场景，严格执行白名单映射即可补齐安全边界。