MySQL服务端不提供连接池功能，连接池由应用层或中间件实现；需调优max_connections、wait_timeout等参数以匹配应用连接池配置，避免连接失效或中断。
MySQL 应用端连接池不是 MySQL 自己配的
MySQL 服务本身不提供连接池功能，connection pool 是应用层（如 Java 的 HikariCP、Python 的 SQLAlchemy + connection pooling、Go 的 sql.DB）或中间件（如 ProxySQL、MaxScale）实现的。MySQL 只负责接受、验证、处理连接请求，并通过 max_connections 等参数限制并发上限。误以为在 my.cnf 里配“连接池”，常导致配置失效或资源错配。
关键 MySQL 服务端参数必须调优
即使连接池在应用侧，MySQL 仍需配合调整，否则池内连接会频繁超时、中断或被强制杀掉：
-
max_connections：设为略高于应用所有实例连接池maxPoolSize总和（例如 4 个服务实例 × 每个池最大 50 连接 = 200，建议设max_connections = 250） -
wait_timeout和interactive_timeout：默认 28800 秒（8 小时），但连接池通常复用连接数小时；若设太小（如 60），空闲连接会被 MySQL 主动断开，池内连接变invalid，下次使用抛MySQL server has gone away -
connect_timeout：影响连接建立失败判定，连接池重试逻辑依赖它；建议保持默认 10，避免过早放弃建连 -
max_connect_errors：若应用频繁启停或测试环境乱填密码，可能触发主机被锁；开发/测试可设大些（如100），生产建议保留默认100并监控Aborted_connects
HikariCP（Java）与 MySQL 配合的典型陷阱
最常见问题是连接池健康检查与 MySQL 超时参数不匹配，导致“看似可用实则失效”的连接被分配给业务线程：
- 不要用
connectionTestQuery = SELECT 1（旧版驱动兼容性差，且不校验连接状态）；应启用connectionInitSql = SELECT 1或更推荐——开启connection-test-query为SELECT 1同时设置validation-timeout=3000 -
idle-timeout必须 小于 MySQL 的wait_timeout（例如 MySQL 设 1800，则 HikariCP 设idle-timeout=1500），否则空闲连接在归还池前就被 MySQL 断开了 -
max-lifetime建议设为1800000（30 分钟），避免长生命周期连接因网络抖动、中间设备超时等意外僵死 - 驱动 URL 加上
?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true（MySQL 8.0+ 必须显式指定时区和公钥获取）
如何验证连接池是否真健康
光看应用日志“Connected”没用，得查实际行为：
- MySQL 侧执行
SHOW PROCESSLIST，观察Command列是否大量为Sleep，且Time接近wait_timeout—— 若是，说明池未及时清理或回收策略不合理 - 监控
Threads_connected和Threads_created：后者持续上涨说明连接反复新建，池没生效（常见于每次 DAO 都 new DataSource） - 应用侧打开 HikariCP 的
metricRegistry，重点盯hikaricp.connections.acquire耗时突增——往往意味着 MySQL 连接数打满，新连接在排队 - 抓包或开启 MySQL
general_log（仅调试），确认应用发来的确实是复用连接（相同thread_id多次执行不同 SQL），而非每次都Connect → Query → Quit
连接池不是设了 maxPoolSize 就万事大吉；MySQL 服务端容忍度、应用池回收节奏、网络稳定性三者必须咬合。一个参数偏移，就可能让池变成“假池”。
