预处理语句仅在同SQL多参数执行时提升性能，省去解析与计划生成；需开启useServerPrepStmts=true、长连接/连接池、及时close()，否则无效甚至更慢。
预处理语句真能提升性能？先看它到底省了什么
MySQL 的 PREPARE + EXECUTE 流程，核心省的是「SQL 解析 + 查询计划生成」这两步。普通语句每次执行都要走完整流程：词法分析 → 语法分析 → 语义检查 → 生成执行计划；而预处理语句在第一次 PREPARE 时就缓存了执行计划，后续只替换参数、复用计划。
但注意：这个优化只在同一条 SQL 多次执行、仅参数不同时生效。如果每次 PREPARE 的 SQL 字符串都变（比如拼接了不同表名或字段），那和普通查询没区别，还多一次网络往返。
- 频繁执行的 INSERT/UPDATE/SELECT 带固定结构、变参数的场景才值得上预处理
- 连接池中每个连接各自维护自己的预处理缓存，不存在跨连接共享
- MySQL 8.0+ 默认开启
prepare_stmt_cache_size，但上限默认只有 16，超了会淘汰旧的，不是无限缓存
Java 中 PreparedStatement 的实际行为 vs 你以为的行为
JDBC 的 PreparedStatement 接口不等于 MySQL 的服务端预处理。是否走真正的服务端预处理，取决于 JDBC URL 参数：
- 默认（
useServerPrepStmts=false）：JDBC 在客户端做参数转义和拼接，发给 MySQL 的仍是普通语句 - 开启（
useServerPrepStmts=true）：才会触发COM_STMT_PREPARE协议，让 MySQL 真正缓存执行计划
常见错误现象：SQLException: Can't create more than max_prepared_stmt_count statements —— 就是开了 useServerPrepStmts=true 但没及时 close()，导致服务端句柄堆积。
- 必须显式调用
ps.close()，不能只靠 try-with-resources（某些老驱动有 bug） - 批量操作时，
addBatch()+executeBatch()比循环executeUpdate()更高效，但前提是 batch size 合理（通常 100–1000 行） - 如果 SQL 含子查询或
IN (?)，JDBC 无法自动展开参数，得手动拼成IN (?,?,?)再 set，否则报错
为什么有时候 PreparedStatement 反而更慢？
不是所有场景都适合。典型反模式：
- 单次执行的查询硬套
PreparedStatement：多了协议交互开销（PREPARE → EXECUTE → CLOSE），比直接Statement.execute()多 2 轮通信 - 使用了
LIKE ?但参数以通配符开头（如%abc），MySQL 无法用索引，而预处理又掩盖了执行计划退化问题 - 参数类型不匹配，比如用
setString(1, "123")给 INT 字段，MySQL 会隐式转换，可能跳过索引，且服务端预处理无法提前发现
性能影响点：
- 服务端预处理启用后，
max_prepared_stmt_count默认值是 16382，超限会报错，需监控SHOW STATUS LIKE 'Com_stmt_prepare'和'Com_stmt_close' - 时间类型参数传
java.util.Date而非java.time.LocalDateTime（JDBC 4.2+），可能触发时区转换，拖慢执行
如何验证预处理是否真正生效
别猜，看 MySQL 服务端日志或状态变量：
- 开启 general_log：执行
SET GLOBAL general_log = ON，然后查日志里有没有Prepare和Execute分离记录 - 查当前连接的预处理句柄数：
SELECT * FROM performance_schema.prepared_statements_instances WHERE OWNER_THREAD_ID = (SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_ID = CONNECTION_ID()); - 对比两次相同查询的
EXPLAIN FORMAT=JSON输出，看"query_plan"是否一致，尤其关注"used_columns"和"index_condition"
容易被忽略的一点：MySQL 的预处理缓存是 per-connection 的，连接断开就全清。如果你用的是短连接（比如 CGI 模式），预处理毫无意义——每次都是新连接、新 PREPARE。长连接 or 连接池才是前提。
