PreparedStatement预编译缓存失效不会报错但导致SQL重复编译、执行计划无法复用；需检查数据库驱动配置（如MySQL需useServerPrepStmts=true）、SQL字符串完全一致（空格/大小写/动态拼接均影响）、连接生命周期是否匹配及开启驱动日志验证。
PreparedStatement 预编译缓存失效通常不会报错，但会导致 SQL 每次都重新编译、无法复用执行计划，进而影响性能。排查关键在于确认缓存是否命中、为何未命中，以及数据库和驱动层面的配置是否匹配。
确认 PreparedStatement 是否真被缓存
不同数据库和 JDBC 驱动对预编译缓存的实现差异较大：MySQL（Connector/J）默认关闭服务端预编译，实际走的是客户端模拟；PostgreSQL 的 prepareThreshold 控制是否触发服务端 PREPARE；Oracle 则依赖连接池（如 HikariCP）或驱动参数 cachePrepStmts=true 才启用客户端缓存。
- MySQL：需显式设置
useServerPrepStmts=true&cachePrepStmts=true，否则即使写conn.prepareStatement(sql)，底层仍是普通 Statement 拼接 - PostgreSQL：默认
prepareThreshold=5，即同一条 SQL 执行满 5 次后才升为服务端预编译；设为 0 表示禁用，设为 1 表示首次就预编译 - Oracle：需开启
cachePrepStmts=true，并配合prepStmtCacheSize（默认 25）和prepStmtCacheSqlLimit（默认 2048）控制缓存容量
检查 SQL 字符串是否“完全一致”
缓存键是原始 SQL 字符串（不含参数值），任何微小差异都会导致缓存不命中：
- 空格、换行、大小写（部分驱动区分）：例如
"SELECT * FROM user"和"select * from user"在某些驱动下视为不同语句 - 别名变化：
"SELECT u.id FROM user u"和"SELECT u.id FROM user t"是两条不同缓存项 - 动态拼接 SQL：在业务代码中用字符串 + 拼出 SQL（如根据条件加 WHERE），每次生成的 SQL 字符串不同，必然无法缓存
- 使用了数据库函数或伪列：如
NOW()、SYS_GUID()等，虽不影响执行，但会让 SQL 字符串固定不下来
验证连接池与 PreparedStatement 生命周期是否匹配
缓存一般绑定在物理连接（Connection）或 PooledConnection 上。若每次获取新连接、或连接被回收重置，缓存即丢失：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- HikariCP 默认启用
cachePrepStmts（需驱动支持），但要求连接未 close；若代码中写了conn.close()，实际归还到池中，缓存仍可复用 - Druid 需配置
poolPreparedStatements=true和maxOpenPreparedStatements（如 -1 表示不限制） - 避免在 finally 块中无条件
conn.close()后又继续用同一 conn —— 这会抛异常，但更隐蔽的问题是提前 close 导致缓存清空
开启驱动级日志定位真实行为
仅靠代码逻辑难以判断底层是否真走了预编译，必须看驱动日志：
- MySQL Connector/J：添加 JVM 参数
-Dcom.mysql.cj.log=DEBUG，搜索Preparing statement或Cached statement - PostgreSQL JDBC：启用
loggerLevel=DEBUG和loggerFile=pgjdbc.log，观察是否出现SimpleBind（非预编译）或Parse/Bind（服务端预编译） - Oracle UCP 或 OJDBC：设置
oracle.jdbc.Trace=true，关注cached statement相关输出
不复杂但容易忽略：缓存是否生效，不能只看代码写了 prepareStatement，而要看驱动配置、SQL 稳定性、连接生命周期三者是否协同。先开日志，再比对 SQL 字符串，最后核对池配置，基本就能定位根因。
