buffalo默认数据库连接池不可调，必须手动配置*sql.db参数；buffalo db migrate与运行时使用独立连接池，database.yml中池参数无效，需在app.go中显式设置setmaxopenconns等。
Buffalo 默认的数据库连接池不可调，必须手动覆盖 pop.Connection 的底层 sql.DB 实例才能生效。
buffalo db migrate 用的连接池和运行时不是同一个
Buffalo 的 buffalo db migrate 命令走的是 CLI 初始化路径，它用 pop.NewConnection 创建独立连接，不复用应用运行时的 pop.Connection。这意味着你在 app.go 里调用 pop.SetConnection 配置的连接池参数，对迁移命令完全无效。
- 迁移脚本执行时用的是临时
*sql.DB，未设置SetMaxOpenConns/SetMaxIdleConns - 运行时 API 请求走的是你手动配置的
pop.Connection，但默认未做任何池参数干预 - 两个连接池各自独立，可能造成 MySQL 侧连接数超限（比如迁移占 20，服务又开 20）
必须在 app.go 中显式配置 *sql.DB 的池参数
Buffalo 的 pop.Connection 底层是 *sql.DB，但它的初始化封装隐藏了池控制入口。你需要在 app.go 的 app.New() 后、app.Serve() 前插入手动配置：
func app() *buffalo.App {
app := buffalo.New(buffalo.Options{
Env: ENV,
SessionName: "_myapp_session",
})
<pre class="brush:php;toolbar:false;">// ... 其他中间件注册
// 获取当前 pop 连接并强转为 *sql.DB
if db, ok := pop.Connection().DB(); ok {
db.SetMaxOpenConns(25)
db.SetMaxIdleConns(10)
db.SetConnMaxLifetime(60 * time.Minute)
db.SetConnMaxIdleTime(30 * time.Minute)
}
return app}
-
SetMaxOpenConns控制最大并发连接数，建议 ≤ MySQL 的max_connections的 70% -
SetMaxIdleConns不宜设为 0，否则每次请求都新建连接，失去池意义 -
SetConnMaxLifetime和SetConnMaxIdleTime必须配对使用，避免 DNS 变更或网络抖动导致 stale connection
database.yml 里的参数对连接池完全无效
Buffalo 的 database.yml 只影响 DSN 解析和 pop 初始化时的基础配置（如 dialect、host、database），poolSize、minIdle 这类 JDBC 风格参数会被 pop 忽略——因为 pop 使用的是 Go 原生 database/sql，不识别这些键。
- 不要在
database.yml里写pool_size: 20，它不会被读取 - DSN 中也不能加
&poolSize=20，MySQL 驱动不认这个 query param - 所有池行为必须通过
*sql.DB方法显式设置，无例外
微服务拆分后每个 service 必须独立配置连接池
当你把单体 Buffalo 拆成多个微服务（如 user-service、order-service），每个 service 的 pop.Connection 是隔离的，但它们共用同一份 database.yml 和初始化逻辑。如果没在各自 app.go 中单独调用 db.SetMaxOpenConns，就可能所有 service 都用默认值（0 表示无上限），瞬间打爆数据库。
- 每个 service 的
app.go都要重复那段if db, ok := pop.Connection().DB()配置 - 不同 service 的池大小应按实际 QPS 和事务复杂度差异化设置（例如查询密集型设高些，写密集型留余量）
- 别依赖 “统一配置中心” 注入池参数——pop 没提供运行时重载接口，改了也白改
最易被忽略的一点：Buffalo 的 pop.Transaction 和 pop.Connection 都不自动继承你设好的 *sql.DB 参数，只要用了 tx := pop.Transaction(...)，就得确保该 tx 底层的 *sql.Tx 来自你已配置的 *sql.DB，否则池策略就断掉了。
