数据库连接池与参数调优【初/中级】
❓ 面试官：为什么项目中要使用数据库连接池？不用会怎样？
频率：🔥🔥🔥🔥
💡 一句话总结（先抛结论）： 使用连接池主要是为了复用连接，减少频繁创建和销毁连接的开销，同时能够控制数据库的最大并发连接数，防止数据库被高并发流量打垮。
📝 详细原理解析： 如果不用连接池（每次需要执行 SQL 时都新建 Connection）：
- 网络开销极大：创建一个 MySQL 连接，需要经过 TCP 三次握手、MySQL 服务端权限校验等多个步骤，耗时远远大于执行一条简单的
SELECT语句本身。 - 资源耗尽风险：在高并发场景下，如果每个请求都去数据库建连接，MySQL 的可用连接数（
max_connections，默认通常只有 151 个）会瞬间被耗尽，导致后续请求全部报Too many connections错误。
引入连接池后：
- 在应用启动时，连接池会预先建立一部分空闲连接（
minimum-idle）。 - 业务需要查数据库时，直接从池子里借（borrow）一个现成的连接，用完后还（return）给池子，而不是关闭它。
❓ 面试官：目前主流的数据库连接池有哪些？你了解它们的区别吗？
频率：🔥🔥🔥
💡 一句话总结（先抛结论）： 目前最主流的是 HikariCP 和 Druid。HikariCP 的核心优势是"极致的性能"（Spring Boot 2.0 后的默认选择）；而 Druid（阿里开源）的核心优势是"强大的监控和 SQL 拦截功能"。
📝 详细对比：
- HikariCP（光速池）：
- 优点：号称目前最快的连接池。代码极其精简，通过字节码级别的优化（如
FastList替代ArrayList）、并发无锁集合、使用自定义的ConcurrentBag等手段将性能压榨到极致。 - 缺点：缺少自带的 UI 监控面板和慢 SQL 统计功能（通常需要借助外部监控如 Prometheus + Grafana）。
- 优点：号称目前最快的连接池。代码极其精简，通过字节码级别的优化（如
- Druid（德鲁伊）：
- 优点：为监控而生。自带 Web 监控控制台，能直观看到连接池状态、慢 SQL 执行次数、SQL 防注入（WallFilter）等。国内大部分传统老项目和政企项目最爱用。
- 缺点：为了统计和监控，加了很多锁和埋点，性能比 HikariCP 稍微差一点点（但在绝大多数业务场景下，这点性能差异可以忽略不计）。
🌟 面试加分项（实战经验）： 选型建议：如果是互联网高并发核心链路服务，且公司有完善的链路追踪监控体系（如 SkyWalking），直接用 SpringBoot 默认的 HikariCP；如果是中后台管理系统，排查慢 SQL 比较费劲，建议用 Druid，它的监控面板能省去很多排查麻烦。
❓ 面试官：如果线上突然报 Connection is not available 或者连接池耗尽，你怎么排查？
频率：🔥🔥🔥🔥
💡 一句话总结（先抛结论）： 连接池耗尽（Connection Leak）通常有两个原因：一是数据库发生了慢查询或死锁导致连接被长时间占用无法归还；二是代码里存在"连接泄漏"（比如开启了事务但中途抛出未捕获的异常导致连接没释放）。
📝 详细排查步骤：
- 先看是不是数据库挂了/慢了：
- 如果系统平时运行正常，突然报连接池耗尽，90% 的概率是因为数据库里出现了慢查询！
- 一个请求拿走连接，本来 10ms 就该还回来，结果因为慢查询执行了 10 秒，这就导致连接被霸占。并发一上来，几十个连接瞬间被借空，后续请求全拿不到连接报错。
- 排查手段：立刻去数据库执行
show processlist;，看是不是有大量正在执行的慢 SQL。
- 看是不是连接泄漏（代码 Bug）：
- 排查代码里是不是有耗时极长的 RPC 调用（比如 HTTP 请求）被包在了
@Transactional事务注解里。 - 只要进了
@Transactional方法，就会立刻从连接池拿走一个连接。如果这个方法里去请求第三方接口花了 5 秒，那么这个数据库连接就被白白挂起占用了 5 秒！ - 排查手段：开启连接池的防泄漏检测机制。例如 HikariCP 可以配置
leakDetectionThreshold=5000（如果一个连接被借走超过 5 秒还没还，就会在日志里打印出借走这个连接的代码堆栈信息，能精准定位到哪行代码没还连接）。
- 排查代码里是不是有耗时极长的 RPC 调用（比如 HTTP 请求）被包在了
🌟 面试加分项（实战经验）：核心避坑准则：在实际开发中，我严格遵循"大事务拆小"原则。严禁把无关的 RPC 调用、发 MQ 消息、甚至文件上传等耗时操作放在带有 @Transactional 注解的方法内部。我会把这些耗时操作放在事务外执行，只有遇到真正需要落库的代码时，才通过编程式事务或拆分出的小方法去加事务，最大程度缩短占用数据库连接的时间。
❓ 面试官：连接池的核心参数怎么设置？比如 maximum-pool-size 设置多少合适？是越大越好吗？
频率：🔥🔥🔥
💡 一句话总结（先抛结论）： 连接池大小绝对不是越大越好！设置过大反而会因为 CPU 频繁的上下文切换和锁竞争导致性能下降。通常推荐的大小是：连接数 = ((核心数 * 2) + 有效磁盘数)。一般单节点配置 10~20 个连接就足够支撑极高的并发了。
📝 核心参数解析（以 HikariCP 为例）：
maximum-pool-size（最大连接数）：- 池中允许的最大连接数（包含空闲和正在使用的）。如果达到上限，新来的请求会被阻塞等待。
- 误区：很多人觉得并发 1000 就该设 1000。大错特错！MySQL 服务端是基于线程的，CPU 核心数有限。如果强行弄 1000 个连接同时发 SQL，MySQL 的 CPU 会把大量时间浪费在线程上下文切换上。
- 经验值：对于一般的 4 核/8 核服务器，连接池设为 10~30 完全足够。
minimum-idle（最小空闲连接数）：- 池中始终保持的空闲连接数。HikariCP 建议不要设置，让它和
maximum-pool-size保持一致，这样可以避免在流量突增时因为临时创建连接而导致的性能抖动（即固定大小的连接池性能最好）。
- 池中始终保持的空闲连接数。HikariCP 建议不要设置，让它和
connection-timeout（连接超时时间）：- 客户端从池子里借连接时，最多等待多久，超时就抛异常。通常设置为 30000ms（30秒）。
idle-timeout（空闲连接超时时间）：- 一个连接空闲多久会被池子主动回收释放。通常设置 600000ms（10分钟）。
max-lifetime（连接最大存活时间）：- 一个连接不管是不是空闲的，只要活过了这个时间，就会被强制回收（防止网络层的静默断开）。必须比数据库的
wait_timeout小！通常设置 1800000ms（30分钟）。
- 一个连接不管是不是空闲的，只要活过了这个时间，就会被强制回收（防止网络层的静默断开）。必须比数据库的