连接池本身不防SQL注入，真正防护靠PreparedStatement；但其配置影响预编译效果：如cachePrepStmts与useServerPrepStmts需配合启用服务端预编译，否则仅客户端模拟仍可被绕过。
连接池配置本身不防SQL注入，但能影响预处理语句行为
数据库连接池（如 HikariCP、Druid）的配置项里没有“SQL注入防护开关”，也不会自动拦截恶意 SQL。它只管连接的创建、复用、回收。真正防注入的是你用 db.Prepare() 还是拼接字符串——池子只是把 Prepare() 背后的物理连接提供得更稳更快而已。
不过，连接池参数会影响预处理语句的实际效果：比如连接复用时，某些驱动会缓存 PreparedStatement 对象；如果连接被错误复用或未清理状态，可能让旧语句残留、参数绑定错乱，间接削弱防护效果。
-
cachePrepStmts=true（MySQL JDBC）必须配合useServerPrepStmts=true才真正走服务端预编译，否则只是客户端模拟，仍可能被绕过 - 若连接池设置了过长的
maxLifetime（如 > 24h），而数据库端启用了wait_timeout=600，连接可能在归还后已失效，下次复用时触发重连+重 Prepare，增加开销且可能暴露异常路径 - 连接池未启用
isValid()或validationQuery="SELECT 1"，僵尸连接可能返回旧的、未清理的预处理句柄，导致参数类型错配或执行计划失效
设置 PreparedStatement 缓存上限的关键参数
预处理语句缓存不是无限的，靠 JDBC 驱动和连接池协同控制。盲目开大反而浪费内存、拖慢 GC，尤其在表名/字段名动态拼接（无法预编译）的场景下，缓存命中率极低。
以 MySQL Connector/J 8.0+ 为例，关键参数必须成对出现才有意义：
-
cachePrepStmts=true：开启客户端预处理语句缓存（默认 false） -
prepStmtCacheSize=250：缓存多少个PreparedStatement对象（默认 25） -
prepStmtCacheSqlLimit=2048：只缓存 SQL 长度 ≤ 2048 字符的语句（默认 256） -
useServerPrepStmts=true：强制走 MySQL 服务端预编译（需数据库支持 PREPARE 语句） -
cacheResultSetMetadata=true：可选，缓存元数据减少解析开销（对防注入无直接作用，但提升稳定性）
注意：prepStmtCacheSize 不是越大越好。实测中超过 500 后命中率增长趋缓，而单个连接对象内存占用上升约 15%～20%。建议从 100 起步，结合 db.Stats().MaxIdleClosed 和 GC 日志观察效果。
为什么不能靠连接池“限制表名/字段名拼接”
连接池完全不解析 SQL 内容，它只传递字节流。像 "SELECT * FROM " + tableName + " WHERE id = ?" 这种写法，无论池子怎么配，只要 tableName 来自用户输入且没白名单校验，就存在注入风险。
这类动态结构只能靠应用层解决：
- 表名/字段名必须来自硬编码枚举或配置白名单，例如
map[string]bool{"users": true, "orders": true} - 避免使用
fmt.Sprintf或+拼接任何非字面量的 SQL 片段 - 若必须动态路由（如分库分表），应由中间件或 DAO 层统一处理，而非透传到 JDBC 层
连接池唯一能做的，是确保这类高危操作失败时快速报错（比如通过 connectionTimeout=3000 避免卡死），而不是帮你过滤。
容易被忽略的实战细节
很多团队调优时盯着 maxPoolSize 和 minIdle，却忘了预处理语句依赖底层连接的状态一致性。几个真实踩过的坑：
- Druid 的
removeAbandonedOnBorrow=true在检测到连接疑似泄露时会强制关闭并重建，但重建后不会清空旧连接上的预处理缓存，导致后续请求拿到“半残”句柄 - HikariCP 默认禁用
isolateInternalQueries，如果应用里误用SELECT 1做健康检查，又同时开了useServerPrepStmts，可能污染服务端 PREPARE 句柄池 - Go 的
database/sql默认不缓存Stmt，每次db.Prepare()都新建——但如果连接被池子复用，而你没显式stmt.Close()，会导致服务端 PREPARE 句柄泄漏，最终触发 MySQL 的max_prepared_stmt_count限制（默认 16382）
所以，防注入的终点不在池子配置，而在你是否每条 Prepare 都配了 defer stmt.Close()，以及是否敢把所有用户输入都扔进 Query 的第二个参数里。
