连接池配置本身不防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 的第二个参数里。
评论(0)