连接池是预创建并复用Connection对象的机制，避免每次SQL都新建TCP连接；实测建连耗时80–150ms，远超SQL执行本身；需合理设maximum-pool-size与minimum-idle，正确归还连接防泄漏。

连接池不是“池子”，而是一套连接复用机制

连接池本质是程序启动时预先创建一批 Connection 对象，放进内存里统一管理，并在后续数据库操作中反复使用它们——而不是每次 executeQuery() 都新建一个物理 TCP 连接。它不改变 JDBC 协议，但彻底绕开了“三次握手→认证→SQL→四次挥手”这套重操作流程。

为什么不用连接池，一条 SQL 会多花 200ms+

实测典型场景下：建立 MySQL 连接平均耗时 80–150ms（含网络延迟、SSL协商、权限校验），关闭连接也有 20–40ms。而真正执行 SELECT COUNT(*) FROM user 可能只要 2ms。也就是说，95% 的时间花在“准备干活”上，不是“干活”本身。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 高并发时大量 TIME_WAIT 状态堆积，Linux 默认 60 秒才能回收，容易占满本地端口
• MySQL 服务端为每个连接分配线程/内存，连接数冲到 200+ 就可能触发 Too many connections
• 频繁 GC：每次 new Connection 产生大量临时对象，JVM 压力陡增

HikariCP 的 minimum-idle 和 maximum-pool-size 怎么设才不翻车

盲目调大 maximum-pool-size 是线上最常见错误——它不会提升性能，只会把数据库压垮。真实经验值来自硬件与负载特征：

• maximum-pool-size 推荐值 = (CPU核心数 × 2) + 有效磁盘数（例如 4 核 SSD 服务器 → 9；若业务含大量 IO 等待，可放宽至 15–20）
• minimum-idle 不建议设为 0：冷启动后首个请求仍要建连，应设为 maximum-pool-size 的 30%～50%，比如最大 20，最小就设 8
• 必须配 connection-timeout（建议 30000），否则连接池取不到连接时会无限阻塞线程

归还连接不是 conn.close()，而是“放回池里”

这是开发者踩坑率最高的点：调用 conn.close() 在连接池环境下 ≠ 关闭物理连接，而是通知池子“我用完了，请回收复用”。但如果忘了这一步，或在异常分支里漏写，就会导致连接泄漏——池子里的可用连接越来越少，最终所有请求卡在 getConnection() 上等待。

• 务必确保每个 try 都配对 finally { if (conn != null) conn.close(); }
• 更安全的做法是用 try-with-resources（JDK 7+），Connection 实现了 AutoCloseable，自动触发归还逻辑
• 启用 HikariCP 的 leak-detection-threshold（如设为 60000），超时未归还会打日志报警

连接池配置不是贴参数就能跑，关键在理解“连接何时创建、谁来释放、超时怎么判、泄漏怎么抓”——这些细节没对齐，再快的池子也会变成单点故障源。