PreparedStatement提高执行效率的关键在于复用：SQL模板必须固定以命中数据库执行计划缓存，且需复用同一语句对象、配合连接池配置与批量操作，而非仅调用prepareStatement()。
PreparedStatement 提高执行效率，关键不在“用了它”，而在于“怎么用”。它的性能优势来自数据库端的执行计划复用和客户端语句对象的合理复用，不是调一次 prepareStatement() 就自动变快。
预编译真正起效的前提：SQL 模板必须固定
数据库只有在收到**完全相同**的 SQL 字符串时，才会命中执行计划缓存。哪怕一个空格、大小写不同、或参数值拼进 SQL 里，都会导致缓存失效。
- ✅ 正确：使用
"SELECT * FROM users WHERE status = ? AND dept_id = ?"—— 占位符统一，模板恒定 - ❌ 错误：拼接出
"SELECT * FROM " + tableName + " WHERE id = " + id—— 每次 SQL 字符串都不同，无法缓存 - ⚠️ 注意：表名、字段名、ORDER BY 子句等不能用
?占位，必须通过白名单校验后拼接（如枚举允许的排序字段）
复用 PreparedStatement 实例，避免频繁创建
每次调用 conn.prepareStatement(sql) 都会新建一个对象，即使 SQL 相同，也会绕过连接池中的语句缓存机制，白白浪费预编译开销。
- 在短生命周期操作（如单次 HTTP 请求）中，可将 PreparedStatement 声明为局部变量，配合 try-with-resources 自动关闭
- 在长周期、高频调用场景（如定时批处理、消息消费循环），应复用同一个 PreparedStatement 实例，仅反复调用
setXxx()和executeUpdate() - 连接池（如 HikariCP）通常支持 statement 缓存，但需开启配置（如
cachePrepStmts=true、prepStmtCacheSize=250）并确保驱动兼容
配合批量操作，放大性能收益
单条执行时，预编译优势有限；但批量插入/更新时，效率提升显著——因为只编译一次，却执行 N 次。
- 用
addBatch()累积多组参数，再用executeBatch()一次性提交 - 注意设置合适的批大小（如 50–100 条），避免内存溢出或事务过大
- MySQL 需在连接 URL 中启用服务端预编译：
?useServerPrepStmts=true&rewriteBatchedStatements=true，否则 JDBC 默认走客户端模拟批处理
驱动与数据库配置不可忽略
预编译能力依赖 JDBC 驱动实现和数据库服务端支持，光写 Java 代码不够。
- MySQL：确认使用较新驱动（8.0+），并开启
useServerPrepStmts=true - PostgreSQL：默认支持，但建议配合
prepareThreshold=1（首次即预编译） - Oracle：使用
oracle.jdbc.autoCommitSpecCompliant=false可优化批量表现 - 务必关闭日志中冗余的「Preparing statement」输出，避免掩盖真实瓶颈
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
