PreparedStatement预编译发生在数据库端或JDBC驱动端：MySQL 8+默认服务端预编译（COM_STMT_PREPARE），不支持时退化为客户端模拟拼接；Oracle、PostgreSQL等原生支持服务端预编译。
PreparedStatement 提升性能的核心在于SQL 语句只编译一次，多次执行复用编译结果，而不是每次执行都重新解析、优化、生成执行计划。
预编译发生在数据库端还是 JDBC 驱动端？
取决于数据库支持和驱动配置：
- MySQL 8+ 默认启用服务器端预编译（
useServerPrepStmts=true），JDBC 向 MySQL 发送COM_STMT_PREPARE命令，由数据库完成语法分析、查询优化、执行计划缓存 - 若关闭服务器预编译（或数据库不支持），驱动会退化为客户端模拟——即在发送前把参数拼进 SQL 字符串，再以普通 Statement 执行，此时不享受真正预编译性能优势
- Oracle、PostgreSQL 等主流数据库均原生支持服务端预编译，只要使用
prepareStatement()且连接配置正确，就能触发
为什么复用编译结果能提速？
每次执行 SQL，数据库需完成多个耗时步骤：词法/语法解析 → 语义校验 → 表与列存在性检查 → 权限验证 → 查询重写 → 生成执行计划（含索引选择、连接顺序等）。这些步骤对结构相同、仅参数不同的语句是重复劳动。
- PreparedStatement 的 SQL 模板（如
"SELECT * FROM user WHERE id = ?"）首次执行时完成全部编译，结果缓存在数据库内存中（如 MySQL 的prepared_statement_cache） - 后续执行只需传入新参数（如
setLong(1, 1005)），跳过解析与优化，直接调用缓存的执行计划 - 尤其在批量操作（如 1000 次插入）中，性能差异可达 2–5 倍
哪些情况真正受益于预编译？
- 同一连接内，相同 SQL 结构被反复执行（如用户登录校验、订单状态更新）
- 使用连接池时，不同请求可能复用已预编译的 PreparedStatement（部分厂商驱动支持跨连接缓存）
- 批处理操作（
addBatch()+executeBatch()），数据库可合并网络往返、批量分配资源 - 避免字符串拼接导致的隐式类型转换（如
WHERE create_time > '2026-09-25'vsWHERE create_time > ?），让数据库准确走索引
怎么确认预编译生效了？
不能只看 Java 代码用了 prepareStatement()，还要验证底层行为：
立即学习“Java免费学习笔记（深入）”；
- MySQL 中查
SHOW PREPARED STATEMENTS，能看到当前连接活跃的预编译语句 - 开启 MySQL general log 或 slow log，观察是否出现
Prepare和Execute分离的日志条目 - JDBC URL 加上
&logger=com.mysql.cj.log.StandardLogger&profileSQL=true，控制台会打印实际发送的协议命令 - 对比执行时间：1000 次循环执行同一条 PreparedStatement vs 同样逻辑的 Statement，差距明显即说明生效
