mysql连接池需依赖第三方库，python中推荐pymysql配合dbutils.pooleddb使用：纯python实现、跨平台好、调试方便、线程安全，适合中小并发场景。
MySQL连接池不是Python或Java自带的，而是靠第三方库实现；选错库或配错参数，比不加连接池还容易出问题。
Python里该用 pymysql 还是 mysql-connector-python？
两者都支持连接池，但底层行为差异很大：
-
pymysql是纯 Python 实现，跨平台好、调试方便，但默认不启用连接池，需配合DBUtils.PooledDB或自己封装；线程安全，适合中小并发（QPS -
mysql-connector-python官方驱动，原生支持pool_size和pool_reset_session，但部分版本存在连接泄漏风险（尤其在异常未捕获时） - 别用
oursql或已停止维护的PyMySQL + SQLAlchemy poolclass=StaticPool组合——它不回收连接，压测时必爆Too many connections
实操建议：新项目优先用 pymysql + SQLAlchemy，开启 pool_pre_ping=True 自动校验连接有效性；老项目若已用 mysql-connector-python，务必升级到 8.0.33+ 并设置 pool_reset_session=True。
HikariCP 和 Druid 在 Java 里怎么选？
这不是“功能多就好”的问题，而是“谁更不容易让你掉坑里”：
-
HikariCP启动快、监控精简、默认配置就合理（比如connection-timeout=30000），但没内置 SQL 审计和防火墙，出问题得靠日志+Prometheus 手动排查 -
Druid自带 Web 控制台、慢 SQL 拦截、防 SQL 注入，适合需要运维可见性的系统；但默认testWhileIdle=false，若不手动开validationQuery=SELECT 1，空闲连接会静默断连 - 绝对避开
C3P0：启动慢、无 JMX 支持、超时逻辑混乱，2024 年后连 Spring Boot 3.x 都不再默认兼容
常见错误：把 HikariCP 的 maximumPoolSize 直接设成 MySQL 的 max_connections 值——这会导致所有应用实例加起来远超数据库上限。正确做法是：单实例最大连接数 ≤ max_connections × 0.7 ÷ 应用实例数。
连接池大小和超时参数怎么算才不翻车？
凭感觉设 maxPoolSize=100 是最常见也最危险的操作。真实值取决于你的硬件和流量特征：
- 估算公式：
maxPoolSize ≈ QPS × avg_query_time_ms ÷ 1000 × 1.5（缓冲系数）；例如峰值 200 QPS、平均耗时 40ms →200 × 0.04 × 1.5 = 12，设为 15 即可 -
minIdle建议设为maxPoolSize × 0.2（如 15→3），避免冷启动时大量建连阻塞请求 -
connection-timeout（获取连接超时）必须 wait_timeout（MySQL 服务端默认 28800 秒），推荐设 3000–5000ms；否则应用卡住等连接，用户先看到超时，DB 却还在傻等 -
maxLifetime必须 wait_timeout，且留至少 60 秒余量；HikariCP 默认 1800000ms（30 分钟），若 MySQL 设了wait_timeout=300（5 分钟），连接必在归还前被 DB 主动 kill
最容易被忽略的一点：MySQL 的 wait_timeout 和 interactive_timeout 必须同步调低（建议 300–600 秒），否则连接池以为连接还活着，实际已被服务端断开，下次复用直接报 Lost connection to MySQL server during query。
连接池本身不解决慢查询，也不能掩盖架构缺陷；它只是把“连接建立”这个确定性开销压到最低。真正卡顿往往来自没索引的 SELECT *、没分页的 OFFSET、或者事务里混了 HTTP 调用——这些，连接池再快也没用。
