预编译语句能减少SQL注入检测开销，因其将参数与SQL模板分离，使检测只需针对缓存的带占位符模板执行一次，而非每次请求都扫描完整SQL字符串。
为什么预编译语句能减少SQL注入检测开销
因为真正的注入检测（如正则匹配、语法树分析）发生在 SQL 字符串拼接完成之后；而预编译把参数和 SQL 模板分离，让数据库驱动在客户端或服务端缓存的是「带占位符的模板」，后续只传入参数值——这意味着检测逻辑只需跑一次模板，不用每次请求都扫描完整 SQL 字符串。
- 检测点从「每条执行语句」收缩到「每个唯一 SQL 模板」
- 缓存命中依赖
PreparedStatement的复用粒度，不是靠应用层手动缓存字符串 - 如果业务中大量使用
String.format或+拼接 SQL，预编译根本不会生效，检测仍需全量扫描
Java 里 PreparedStatement 缓存实际生效的条件
JDBC 驱动本身不自动缓存 PreparedStatement，是否复用取决于连接池配置和驱动实现。比如 HikariCP 默认关闭 cachePrepStmts，MySQL Connector/J 需显式开启才能缓存解析后的语句结构。
- 必须启用连接池的预编译缓存：
cachePrepStmts=true - 设置最大缓存数量：
prepStmtCacheSize=250（默认是 25，通常不够） - 指定缓存 key 的长度上限：
prepStmtCacheSqlLimit=2048（太短会导致长 SQL 总是 miss） - PostgreSQL 的
pgjdbc需配合prepareThreshold=1才会走二进制协议预编译
误以为“用了 PreparedStatement 就安全”导致的漏检
很多检测工具在拦截 executeQuery 时，只检查调用栈是否含 PreparedStatement 类名，却忽略实际执行的 SQL 是否已被动态拼接过。一旦出现 String sql = "SELECT * FROM user WHERE id = " + input; 再传给 prepareStatement(sql)，检测就完全失效。
- 真正该检测的是
sql变量的来源，而不是prepareStatement方法调用本身 - ORM 如 MyBatis 的
${}语法会直接拼接，绕过预编译，#{}才走PreparedStatement - Spring JDBC 的
JdbcTemplate.update(String sql, Object... args)是安全的，但update(String sql)重载不带参数，就是裸 SQL
检测性能瓶颈常出现在参数序列化环节
某些 SQL 注入检测模块会在 setString、setInt 等 setter 调用时，对参数值做敏感字符扫描。这看似精准，实则把 O(1) 的参数赋值变成了 O(n) 的逐字符判断，尤其当参数是大文本（如 JSON、HTML 片段）时，延迟陡增。
- 更合理的做法是在
execute阶段统一检测最终绑定的 SQL 字符串，而非每个 setter - 避免对
byte[]、Blob、Clob类型参数做全文扫描，它们几乎不可能构成注入上下文 - 若必须实时检测，可用布隆过滤器快速排除明显安全的值（如纯数字 ID），再对可疑值走正则
检测逻辑越靠近执行终点，覆盖越全；越往上游（如 setter）塞检测，性能损耗越不可控。别信“只要用了 PreparedStatement 就万事大吉”，模板是否真被缓存、参数是否真没被提前拼过、检测时机是否合理——这三个点，少一个，优化就归零。
