mysql 8.0服务端本身不提供连接池，所谓“配置连接池”实为配置客户端驱动或中间件（如hikaricp、aiomysql、mysql2），需在应用侧设置maximum-pool-size、connection-timeout等参数，并确保与服务端max_connections、认证插件及超时参数协同。
MySQL 8.0 服务端本身不提供连接池组件，所谓“配置 MySQL 连接池”，实际是配置你用的客户端驱动或中间件（如 HikariCP、aiomysql、mysql2 + generic-pool），不是改 my.cnf 或启用某个 MySQL 内置模块。
为什么直接改 max_connections 不起作用
max_connections 只是 MySQL 服务端允许的最大并发连接数上限，它不参与连接复用逻辑。如果应用每次请求都调用 mysql.connect() 或 new Connection() 再立刻 close()，哪怕 max_connections = 1000，照样会：频繁触发 TCP 三次握手和身份认证、产生大量 TIME_WAIT socket、报 Too many connections（因为连接未复用，瞬间涌进太多新连接）。
真正控制复用行为的，是客户端侧的连接池实现及其参数。
- Java 项目必须在 Spring Boot 的
application.yml或 HikariCP 手动构建代码里配maximum-pool-size和connection-timeout - Python 异步项目用
aiomysql.create_pool()时，minsize/maxsize才是关键，不是my.cnf里的任何值 - Node.js 用
mysql2时，得配合generic-pool或mysql2/promise的createPool()，且必须设waitForConnections: true和queueLimit: 0
HikariCP 的 maximum-pool-size 和 connection-timeout 怎么设
这两个参数直接影响短连接场景下的吞吐与故障恢复能力。盲目设大反而降低性能。
-
maximum-pool-size建议从12～20起步，OLTP 场景下超过30后常因锁竞争和上下文切换导致 QPS 下降；若应用线程数固定为 20，池子设成 50 就是浪费 -
connection-timeout默认30000（30 秒），线上必须缩到1000～3000；否则一次 DNS 解析失败或网络抖动会让一个业务线程卡死半分钟 - 必须配
connection-test-query: SELECT 1（MySQL 8.0.22+ 推荐用isValid()方法替代），否则失效连接可能被返回给业务，抛出Communications link failure
示例（Spring Boot）：
spring:
datasource:
hikari:
maximum-pool-size: 16
connection-timeout: 2000
connection-test-query: SELECT 1
idle-timeout: 600000
max-lifetime: 1800000
aiomysql.create_pool 的几个默认陷阱
aiomysql.create_pool() 看似一行就能建池，但几个默认值在生产环境极易引发连接耗尽或响应延迟：
-
minsize默认是1，意味着空闲时只保活 1 个连接，突发流量来临时要现场创建，失去池的意义；建议设为5～10 -
maxsize默认是10，对中等并发服务明显偏小；需结合 MySQL 的max_connections设置，例如 MySQL 设了300，应用侧多个实例共用，单个 aiomysql pool 就不该超过50 - 没配
pool_recycle（单位秒）的话，长连接可能因防火墙或中间设备超时被静默断开，后续请求拿到失效连接直接报错；建议设3600（1 小时）强制重连 - 不设
connect_timeout和read_timeout，底层 socket 会沿用系统默认（可能几十秒），掩盖真实网络问题
MySQL 服务端配套要检查的三项
客户端池子配得再好，服务端限制或兼容性问题也会让效果打折扣：
-
max_connections必须 ≥ 所有应用实例的连接池maxsize总和 × 1.2（留余量），否则池子想扩也扩不了 - MySQL 8.0 默认认证插件是
caching_sha2_password，旧版PyMySQL或未更新的mysql-connector-java会静默降级失败，日志里只显示Access denied；确认驱动版本支持，或临时改用户插件：ALTER USER 'xxx'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; -
wait_timeout和interactive_timeout建议设为28800（8 小时）以上，避免连接池里的空闲连接被 MySQL 主动踢掉，造成归还时报错
连接池不是“一配就灵”的开关，它的有效性高度依赖客户端参数、服务端容量、网络稳定性三者的对齐。最容易被忽略的是：把池子最大值设得比 MySQL 的 max_connections 还大，或者忘了驱动对 caching_sha2_password 的兼容性要求——这两点一旦出问题，现象都是连接随机失败，但根本原因藏得很深。
