SQL注入的本质是用户输入被拼接到SQL字符串中执行，与连接池配置无关；防御关键在于禁用字符串拼接、优先使用execute()参数化查询，并对动态对象实施白名单校验。
不会。连接池配置不当本身不会引发 SQL 注入，但它可能掩盖注入漏洞的暴露迹象，或放大其危害范围。
连接池配置和 SQL 注入是两类独立问题
SQL 注入的本质是用户输入被拼接到 SQL 字符串中执行，与数据库连接如何复用无关。连接池（如 mysql2 的 createPool）只负责管理 TCP 连接生命周期、复用空闲连接、限制并发数——它不解析、不校验、不重写你传给 query() 或 execute() 的 SQL 字符串。
常见误解来源：当连接池开启多语句支持（multipleStatements: true）且搭配不安全的 query() 时，攻击者可能一次注入多个语句（如 1; DROP TABLE users;），但这仍是 query() 拼接导致的，不是连接池“造成”的。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
为什么有人觉得连接池配置“导致”注入？
实际是以下几种情况混淆了因果：
- 开发者误以为连接池自动启用预编译——但
query()在池中仍默认走字符串插值，execute()才强制 PREPARE - 连接池复用连接后，错误日志被吞掉或延迟上报，让注入行为更难被监控发现
- 高并发下连接池耗尽 + 注入查询堆积，导致数据库报错混乱（如
ER_PARSE_ERROR），误判为配置问题
真正该盯紧的两个地方
防范注入，必须卡死在 SQL 构建环节：
- 永远优先用
execute()，禁用带字符串拼接的query()；哪怕用了连接池，query("SELECT * FROM users WHERE id = " + req.params.id)依然危险 - 动态表名/列名必须白名单校验，例如：
if (!["users", "orders"].includes(userTable)) throw new Error("invalid table")；execute()对这类场景完全无能为力
连接池配错（比如 connectionLimit 设太小导致请求排队、waitForConnections 设 false 导致直接失败）会影响可用性，但不会把安全的 execute() 变成不安全的。真正的风险点，始终在那一行 SQL 字符串是怎么生成的。
