最大连接数是防崩溃的熔断开关，而非性能指标；sql注入引发dos时，超限连接会放大破坏力，因恶意低效查询长期占用连接，导致连接池耗尽、数据库线程飙升、服务雪崩；合理配置maxpoolsize（≤mysql max_connections并留20%余量）并设置明确超时策略，才能实现分级止损与快速失败。
最大连接数不是性能指标，而是防崩溃的熔断开关——SQL注入引发的拒绝服务（DoS）下，它直接决定系统是缓慢降级还是瞬间雪崩。
为什么超限连接会放大SQL注入的破坏力
攻击者用 ORDER BY RAND() 或嵌套 CROSS JOIN 构造低效查询时，每个连接会卡住数秒甚至更久。如果连接池不限制上限，应用会不断向数据库申请新连接，直到：
- MySQL 的
max_connections被打满，后续所有请求直接报Too many connections - 连接池内部队列积压，等待超时抛出
Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. - 数据库线程数飙升，CPU 占满，连健康检查都响应不了
这时哪怕只有一条恶意请求，也能让整个服务不可用。限制最大连接数，本质是给攻击者设一道“带宽墙”——他最多只能拖住你预设的那几十个连接，其余请求仍可排队或快速失败，不至于全局瘫痪。
maxPoolSize 和 MySQL max_connections 怎么配才不打架
两者必须协同设置，否则会出现“池子没满，库已爆”的尴尬：
- 先查 MySQL 实际上限：
SHOW VARIABLES LIKE 'max_connections';（默认常为 151） - 连接池的
maxPoolSize必须 ≤ 这个值，建议留 20% 余量（例如 MySQL 设为 500，则池子设 400） - 若多个服务共用同一 MySQL 实例，还要按用户拆分：
SET GLOBAL max_user_connections = 100;，再对应调低各服务的maxPoolSize - Druid/C3P0 等池子若未显式配置
maxPoolSize，默认可能是 100 或 8，极易被高并发冲垮
典型错误配置：maxPoolSize=512 但 MySQL max_connections=151 → 启动即报错，或运行中突现 Data source rejected establishment of connection。
光设 maxPoolSize 不够，还得配等待策略和超时
连接池满后的行为，比“设多大”更关键：
-
maxWait（Druid）或checkoutTimeout（C3P0）必须明确设值，比如 3000ms；不设等于无限等待，请求线程全卡死 - 避免用默认 15s 等待：用户感知就是“页面转圈 15 秒后突然报错”，体验极差
- 配合业务做分级：读接口可设短超时（500ms），写接口允许稍长（2000ms），但绝不允许无限制等
- 日志里盯紧
poolActiveCount和poolWaitThreadCount（Druid 监控项），一旦后者持续 > 0，说明连接已成瓶颈，得查慢 SQL 或注入点
没有超时控制的连接池，就像没装刹车的汽车——限速（maxPoolSize）只是辅助，真正救命的是踩刹车（超时中断）的动作。
为什么不能靠“加大连接数”来扛注入攻击
这是最典型的误判：
- 加连接数 ≠ 提升吞吐：每个连接都吃内存、占 CPU 上下文，到一定阈值后，性能反而断崖下跌
- SQL 注入的恶意查询本身不耗资源少，而是故意“卡住”连接；你加 10 倍连接，等于给攻击者 10 倍的卡顿杠杆
- 真实瓶颈往往在单条查询执行上（如全表扫描 +
RAND()），不是并发能力问题 - 根本解法永远是参数化查询 + 输入白名单 + 最小权限，
maxPoolSize只是兜底止损，不是防护主力
把连接池当防火墙用，就像用门锁防地震——震源在 SQL 层，锁再厚也没用。真正要盯的，是 PreparedStatement 是否全覆盖、是否所有用户输入都进了绑定参数、数据库账号有没有被授予 FILE 或 PROCESS 这类高危权限。
