第 67 期 sql 连接池分析

[KippaZou]

【Go 夜读】 sql 连接池分析

大纲

1. sql 连接池简介
2. 连接池的工作原理
3. sql 包连接池源码分析
4. 连接池使用 tips

分享者自我介绍

我叫邹文通，来自早安科技，是一名 golang 后端工程师。

分享时间

2019-11-14 21:00:00 UTC+8

Slides

• https://docs.google.com/presentation/d/1TyNlvfrgOZGvI-TpxtHAYvx6J4U2yBcAz9xzjrU3NDQ/edit?usp=sharing

参考资料

• Go组件学习——database/sql数据库连接池你用对了吗
• Go组件学习——手写连接池并没有那么简单
• Chapter 8 Connection Pooling with Connector/J
• 彻底弄懂mysql（二）--连接方式
• Production-ready Database Connection Pooling in Go

[eddycjy]

@KippaZou database/sql 中 MaxIdleConns 和 MaxOpenConns 应该怎么设置才是相对合理的，在选择设置具体的值时，他们又受什么因素影响呢？

[KippaZou]

@KippaZou database/sql 中 MaxIdleConns 和 MaxOpenConns 应该怎么设置才是相对合理的，在选择设置具体的值时，他们又受什么因素影响呢？

• 关于这个问题，可以参考这篇文章 Production-ready Database Connection Pooling in Go. 文章的建议是 MaxOpenConns 应该和实际的打开的连接数的监测值相关。然后按照 MaxOpenConns 的一定比值设置 MaxIdleConns，比方说 50%，这个值取决于你对业务的预估。每维持一个闲散连接，会造成 1MB 左右的客户端内存开销和 2MB 左右的数据库内存开销，CPU 开销相对小一点。文章还给出了一些 benchmark 的测试，在默认 MaxIdleConns 和 MaxIdleConns = 50% * MaxOpenConns 情况下的一个性能的对比，可以参考一下。

[chuweijia1995]

幻灯片失效了，可以再分享下吗 谢谢~

[KippaZou]

• go 1.11.1 版本的 MaxIdleConns (含义是因连接池已满而关闭的连接数)计算存在 bug，实际上计算的是连接被放回连接池的次数，也就是连接复用的次数，与字段的含义不符。使用 go 1.11.1 及以前版本监测 MaxIdleConns 得到的结果是不正确的，会产生误导。修复详见：https://go-review.googlesource.com/c/go/+/138578
• 该修复在 go 1.11.2 版本 release，因此监测正确的 MaxIdleConns 需升级到 1.11.2 及以上版本。详见: https://github.com/golang/go/issues?q=milestone%3AGo1.11.2

[Awezome]

请教下SetConnMaxLifetime的时间设置比wait_timeout小，每天还会出现个别的 invalid connection，这种情况遇到过没

[KippaZou]

请教下SetConnMaxLifetime的时间设置比wait_timeout小，每天还会出现个别的 invalid connection，这种情况遇到过没

我们没有遇到过这种情况，理论上出现这种情况还有几种可能，一个是 wait_timeout 是在终端形式的连接器里查的，不是在非终端的形式中中查的，设置的实际上还是 interactive time out；还一种可能是用的 mysql-driver 版本有点老，1.5 版本的 mysql driver 对于这种情况有个保护，会在 write packet 的时候检验连接的有效性，如果连接无效，会返回一个 ErrBadConn，sql.DB 会取一条新的连接。