preparedstatement 更安全是因为sql结构与参数分离，参数不参与解析；复用时更快因可缓存执行计划；设null需用setnull(1, types.varchar)；in语句需动态占位符或分批处理。
PreparedStatement 是 JDBC 中最常被问到的核心组件之一，面试官通常不是只考“是什么”，而是想确认你是否真用过、是否理解底层逻辑、有没有踩过坑。回答时抓住三点：预编译本质、安全性优势、实际使用细节。
为什么 PreparedStatement 比 Statement 更安全？
它能防止 SQL 注入，根本原因不是“用了占位符”这么表面——而是数据库驱动在发送 SQL 前，已将 SQL 结构和参数完全分离。参数值不会参与 SQL 解析，而是作为独立数据传给数据库执行引擎。比如：
-
Statement：拼接字符串
"SELECT * FROM user WHERE name = '" + name + "'"，若name = "张三' OR '1'='1"，就变成非法查询； -
PreparedStatement：写成
"SELECT * FROM user WHERE name = ?"，再调用ps.setString(1, "张三' OR '1'='1")，数据库会把整个字符串当普通文本处理，不会解析其中的单引号逻辑。
PreparedStatement 真的更快吗？什么时候体现？
快的前提是复用。首次执行时，它要经历 SQL 解析、生成执行计划、缓存计划等步骤，和 Statement 差不多；但第二次起，只要 SQL 字符串完全一致（注意：不能动态拼表名或列名），数据库可直接复用已编译的执行计划。
- 适合场景：同一 SQL 多次执行（如批量插入、定时任务查固定条件）；
- 不体现优势的场景：每次 SQL 都不同（比如把日期、ID 拼进 SQL 字符串里），那预编译毫无意义，甚至因额外封装略慢；
- 小提示：MySQL 默认开启
preparedStatementCacheSize，Oracle 也有类似的 SQL Area 缓存机制。
怎么给 PreparedStatement 设置 NULL 值？
不能用 setString(1, null) 这种方式——部分老驱动会报错或行为不一致。标准做法是调用 setNull()，并明确指定字段的 SQL 类型：
-
ps.setNull(1, Types.VARCHAR)—— 对应字符串类型字段； -
ps.setNull(2, Types.INTEGER)—— 对应 int/Integer 字段； - 类型常量定义在
java.sql.Types，比如Types.DATE、Types.BOOLEAN等。
它不能直接支持 IN 语句，怎么办？
这是高频实战痛点。因为 WHERE id IN (?, ?, ?) 的问号个数不确定，无法提前 prepare。常见解法有三种：
- 动态构建固定长度的占位符串（如最多 100 个 ID，就写 100 个
?，不足的用setNull或无效值填充）； - 拆成多个小批量执行（比如每 50 个一组，循环调用同一 PreparedStatement）；
- 改用临时表或数据库特性（如 MySQL 的
FIND_IN_SET或 Oracle 的TABLE(CAST(... AS ...))），但需权衡可移植性。
不复杂但容易忽略：用完必须 close PreparedStatement 和 Connection，否则连接池资源会被耗尽；批量操作记得开 addBatch()/executeBatch()，别用单条 executeUpdate 循环。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
