maximumPoolSize应≤max_connections×0.7，如RDS为1000则总池大小≤600；四核实例建议设20，超20易触发上下文切换雪崩；需结合db.Stats()监控真实连接分布。
maximumPoolSize设成多少才算合理
不是看接口QPS，而是看数据库能扛住多少并发线程。MySQL每条连接对应一个OS线程，四核数据库实例，maximumPoolSize超过20就容易触发上下文切换雪崩——你看到的“接口变慢”，其实是CPU在疯狂切线程，不是SQL慢。
实操建议：
- 先查数据库的
max_connections值（比如SHOW VARIABLES LIKE 'max_connections';），maximumPoolSize最多设为它的60%～70%，留出空间给DBA、备份、监控等后台连接 - 用
show processlist观察高峰期活跃连接中真正执行SQL的占比，如果Sleep状态连接长期占80%以上，说明池子虚胖，该砍了 - Kratos服务若走gRPC+HTTP双协议，别按总QPS算，要拆开看：HTTP请求常带前端等待，gRPC调用更密集，优先保障gRPC链路的连接水位
Go标准库database/sql里怎么配才不冲突
Kratos默认用database/sql，但很多人只调SetMaxOpenConns，忘了它和SetMaxIdleConns、SetConnMaxLifetime是联动关系。三者配错，maximumPoolSize就形同虚设。
常见错误现象：connection is not available报错频发，但db.Stats().OpenConnections显示远没到上限。
实操建议：
-
SetMaxOpenConns(20)—— 这才是Kratos服务真正的maximumPoolSize，必须和HikariCP的maximum-pool-size语义对齐 -
SetMaxIdleConns(10)—— 不能大于MaxOpenConns，否则空闲连接会卡住释放逻辑，导致连接泄漏假象 -
SetConnMaxLifetime(1h)—— 避免连接被MySQL主动KILL后，应用还试图复用；时间太短（如5m）会引发频繁重连，抵消池子价值
为什么调大maximumPoolSize反而让慢查询更致命
一条没走索引的SQL跑8秒，如果池子只有5个连接，最多拖住5个请求；设成50，等于把50个业务线程全锁死在同一条慢路上——这不是提升并发，是批量制造超时。
这问题在Kratos里尤其隐蔽：gRPC超时默认是10秒，而connectionTimeout（如HikariCP的connection-timeout）常设30秒，用户早收到gRPC timeout了，连接还在池里挂着。
实操建议：
- 把
connectionTimeout设成略小于业务层超时（比如gRPC设9秒，连接池设7秒），让失败快速暴露，避免连接被慢事务长期霸占 - 配合
SetConnMaxIdleTime（Go 1.19+）或idleTimeout（HikariCP），主动清理空闲太久的连接，防止它们在池里“装死” - 在Kratos中间件里加一层连接借用前检查：若当前
db.Stats().WaitCount > 5，直接打点告警，比等CPU飙高再救火快得多
微服务多仓库场景下，连接池大小怎么分
一个Kratos服务连多个库（比如user_db、order_db、log_db），如果共用一套maximumPoolSize配置，小库会被大库流量挤爆。
实操建议：
- 每个
*sql.DB实例单独配参，不要复用同一个连接池对象——Wire注入时用不同ProviderSet隔离 - 读写分离库必须拆池：
write_db按写吞吐配（比如SetMaxOpenConns(15)），read_db按读QPS配（比如SetMaxOpenConns(30)），避免写操作阻塞读 - 日志库、配置库这类低频库，
SetMaxOpenConns(2)足矣，设太高反而增加MySQL无谓负担
连接池参数不是越“满”越好，而是越“准”越好。最常被忽略的是：Kratos服务启动后，没人去看db.Stats()返回的真实连接分布——活跃数、空闲数、等待数、最大打开数，这四个数字比任何配置项都诚实。
