PreparedStatement 比 Statement 更快，核心在于数据库预编译与执行计划复用：SQL 模板一次编译、多次参数绑定，避免重复解析优化；支持跨连接缓存、网络传输更轻、批量操作更高效，高频或批量场景下性能提升达 2–5 倍。
PreparedStatement 比 Statement 更快，核心在于数据库层面的预编译与复用机制，而不是 Java 侧的代码执行速度差异。
SQL 语句只编译一次
PreparedStatement 在创建时（connection.prepareStatement(sql)）就将带问号的 SQL 发送给数据库，数据库完成语法解析、语义检查、查询优化和执行计划生成，并把该计划缓存起来。后续每次 executeQuery() 或 executeUpdate()，数据库跳过编译环节，直接绑定新参数、复用已有执行计划。
Statement 每次执行都要把完整 SQL 字符串发给数据库，数据库必须从头开始解析、校验、优化、生成新计划——哪怕只是 WHERE id = 1 和 WHERE id = 2 这样结构完全一致的语句，在数据库眼里也是两条不同语句，无法共享计划。
执行计划可跨连接复用
主流数据库（如 MySQL 5.7+、Oracle、PostgreSQL）会对预编译语句的执行计划做全局缓存。只要 SQL 模板相同（例如 SELECT * FROM orders WHERE status = ?），无论来自哪个应用线程、哪个 Connection，只要命中缓存，就能直接调用已编译逻辑。
立即学习“Java免费学习笔记（深入）”；
Statement 的 SQL 是“即拼即用”，数据库很难稳定识别其结构一致性，基本不缓存其执行计划——即使某些版本 MySQL 尝试对简单语句做轻量缓存，也缺乏可靠性，不能作为性能依据。
网络传输更轻量
PreparedStatement 执行时，只需把二进制参数值（比如一个整数 42 或字符串 "alice"）传给数据库；而 Statement 必须把整个拼接好的 SQL 字符串（如 "SELECT * FROM users WHERE name = 'alice'"）完整发送，字符长度更长、编码更耗资源，尤其在高并发或低带宽场景下差异明显。
批量操作天然适配
PreparedStatement 支持高效的 addBatch() + executeBatch()。数据库可将多组参数一次性绑定到同一个预编译模板上，内部以向量化方式处理，减少往返次数和上下文切换开销。
Statement 的批量操作本质仍是多次发送不同 SQL 文本，无法享受模板复用红利，驱动层也难以深度优化。
不复杂但容易忽略：这种性能优势在单次查询中几乎不可测，但在高频访问（如每秒数百次用户查询）、批量导入（如万级数据插入）或连接池复用场景下，差距可达 2–5 倍以上。
