Shuai's Blog

MySQL连接池配置指南：别让数据库被你的"慷慨"压垮

Sat, 07 Feb 2026 00:00:00 GMT

把 MySQL 连接池调好，本质上是在做一件事：在数据库可承受范围内，用最少的连接，稳定地服务住高峰并发。这不是玄学，是一组可以推理的工程权衡。

一句话核心观点#

连接不是越多越好，连接是”共享的稀缺资源”，不是”免费的并发开关”
连接池的目标不是”抗住所有请求”，而是”把压力挡在应用层”

一、你在给谁配？先想清楚这三个对象#

配置连接池前，必须同时看三方：

MySQL 本身 —— 它的承受能力是天花板
单个应用实例 —— 它的 CPU 核数决定了真实并发能力
整个应用集群 —— 实例数乘以单实例连接数，才是 MySQL 真正面对的压力

很多事故的根源在于：👉 单实例看着没问题，集群一扩容，MySQL 直接被连接数打爆。就像一个人能扛 50 斤，你让 10 个人同时往他身上扔 50 斤，他肯定扛不住。

二、MySQL 侧的硬约束（地心引力）#

1. max_connections 是硬天花板#

这是 MySQL 能同时处理的最大连接数。

经验值判断：

每个连接 ≈ 2–10 MB 内存（取决于配置）
连接越多，上下文切换、锁竞争、buffer 抖动越严重

现实结论：

MySQL 通常在 200–500 个活跃连接 内效率最高
上千连接还能活，但性能开始退化
连接池不能突破这个上限，只能更聪明地使用它

2. MySQL 不擅长”超高并发短查询”#

MySQL 更像一个 老派工匠：

喜欢少量连接，每个连接跑得久一点
批量、顺序、可预测的工作方式

它 不擅长：

上千连接同时抢 CPU
大量连接在”连 / 查 / 断”之间频繁抖动

这决定了：连接池要”限流”，不是”放水”。就像给老工匠安排工作，不能让他同时接 100 个急单，他会崩溃的。

三、应用侧：一个实例该开多少连接？#

这是最关键、也是最容易配错的地方。

1. 先看你的应用模型#

问自己三个问题：

是不是 IO 密集型？
- 普通 Web / API 服务：是
- 大量 CPU 计算：不是
单个请求会不会串行访问 DB 多次？
- 是 → 更需要连接余量
- 否 → 连接数可以更小
DB 查询耗时大概多少？
- 5–10ms：连接用得快
- 100ms+：连接会被占住

2. 一个非常实用的估算公式（工程经验）#

单实例最大连接数 ≈ CPU 核数 × 2 ~ 4

例如：

4 核 → 8 ~ 16
8 核 → 16 ~ 32

理由很朴素：同一时刻真正能跑 SQL 的线程 ≈ CPU 核数，多出来的连接只是在排队或制造切换成本。就像一个 4 核 CPU 的厨房，最多 4 个厨师能同时炒菜，再多的人只能排队等锅。

如果你发现：

CPU 没满
连接却经常打满

那不是连接池太小，是 SQL 慢、事务太长或索引有问题。这时候加连接就像给堵车的高速公路加车道，治标不治本。

3. 不要把”并发数”直接映射成”连接数”#

这是经典误区：“我 QPS 很高 / 并发很大，所以我需要很多连接”。

错。连接池靠的是复用，不是一一对应。真正的关系是：

1
连接数 ≈ 并发请求数 × 单次 DB 占用时间

缩短 SQL 时间，比加连接有效得多。就像餐厅翻台率提高了，同样的桌子能服务更多客人，不需要加桌子。

四、集群视角：真正容易翻车的地方#

假设：

MySQL max_connections = 500
你有 10 个应用实例

如果你给每个实例配：maxOpenConns = 100

那么上线那一刻，MySQL 理论最大连接数是：10 × 100 = 1000 ❌

数据库会先死给你看。

正确做法是反推：

1
单实例最大连接数 ≤ max_connections / 实例数 × 安全系数

例如：500 / 10 × 0.7 ≈ 35

这比”拍脑袋 100”安全得多。就像给 10 个人分蛋糕，不能每个人都想拿最大的一块，得先看看蛋糕有多大。

五、连接池三个核心参数详解#

以 Go 的 database/sql 为例（思想对其他语言通用）：

1. MaxOpenConns —— 连接池的”硬天花板”#

这是 硬上限：

平时不一定用满
用满说明你已经在排队

作用机制：

第 1 个请求来 → 建立第 1 个连接
…
第 8 个请求来 → 建立第 8 个连接
第 9 个请求来 → 不能再建连接了，只能等

MaxOpenConns 是限流器，不是性能开关。它保证：

MySQL 不会被瞬间打爆
慢 SQL 不会无限扩散

建议：

小而克制
和实例数联动计算

2. MaxIdleConns —— 连接的”保温箱”#

作用：

减少频繁建连
但空闲连接也占资源

工作原理： 高峰过后，8 个连接被归还给连接池。连接池最多只留 4 个空闲连接，多余的 4 个会被立刻关闭。

为什么不全留？因为：

空闲连接 ≠ 免费
每个连接占内存、线程、buffer
长期空闲连接更容易”悄悄失效”

MaxIdleConns 决定的是”平时我背多少连接成本”。就像保温箱，太大浪费电，太小饭菜凉得快。

经验值：

等于或略小于 MaxOpenConns
对延迟敏感服务可以偏大
对 DB 压力大的系统可以偏小

3. ConnMaxLifetime —— 连接的”寿命上限”#

作用：

避免 MySQL / NAT / LB 偷偷断连接
让连接的内存状态周期性归零
减少”跑几天就慢”的玄学问题

工作原理： 某个连接已经存在了 6 分钟，即使它现在很健康，下次它被归还到连接池时，连接池发现：你活太久了。它会被关闭，下次再需要时，新建一个。

这解决的是三类慢性问题：

MySQL / LB / 防火墙中途断链
连接内存状态长期膨胀
运行几天后开始”莫名其妙变慢”

它不是为了性能，是为了 长期稳定性。就像人需要定期体检，连接也需要定期”换血”。

建议：

1–5 分钟一个量级
一定要 小于 MySQL 的 wait_timeout

4. 把三者放在同一条时间线上#

可以把一个连接的一生画成这样：

1
[ 创建 ]
2
   ↓
3
[ 被请求使用 ] ←—— 多次
4
   ↓
5
[ 归还池中（Idle） ]
6
   ↓
7
[ 超过 MaxIdleConns？] —— 是 → [ 立即关闭 ]
8
   ↓ 否
9
[ 超过 ConnMaxLifetime？] —— 是 → [ 关闭 ]
10
   ↓ 否
11
[ 等待下一次使用 ]

而 MaxOpenConns 始终在旁边盯着：“我最多允许同时存在 8 个你们。“

5. 三个参数的”分工关系”#

一句话总结它们的角色：

MaxOpenConns 👉 控制”最多能有多少连接活着”（安全阀）
MaxIdleConns 👉 控制”高峰过后留多少备用连接”（成本 / 延迟平衡）
ConnMaxLifetime 👉 控制”单个连接活多久”（长期健康）

它们解决的是 完全不同维度的问题，不能互相替代。就像人体的免疫系统、消化系统、神经系统，各司其职，缺一不可。

6. 配置不当的后果#

只调 MaxOpenConns，会怎样？#

高峰时能顶住，但连接可能：

永久不释放
内存膨胀
被中间设备掐死
系统跑几天就开始抽风

就像只顾着招人，不管人员流动，最后公司里全是老员工，效率低下。

Idle 配太大，会怎样？#

MySQL 长期背着大量空闲连接
新实例上线瞬间连满
运维看着一堆 Sleep 连接发愁

就像餐厅里空桌子太多，占着地方不赚钱。

不设 ConnMaxLifetime，会怎样？#

系统一开始很稳，几天后：

偶发 “bad connection”
性能抖动
重启服务后神奇恢复

这是经典症状。就像一个人长期不体检，突然有一天倒下了。

最后一句工程真相#

连接池不是”多快”的工具，是”别死”的工具。

这三个参数一起，做的是同一件事：让数据库连接像新陈代谢一样——有上限、有休息、有淘汰。

理解成”生态系统”，而不是”数字开关”，你就很难配错了。

六、通用公式：一条能直接上线的经验法则#

好，这里给你一个 真的能用、而且不容易被滥用的”通用公式”。它不是数学定律，是工程学里的”安全近似”，在 大多数业务、尤其是后台 / API 服务 里都站得住。

通用结论版（先记住这一行）#

1
单实例 MySQL 最大连接数 ≈ min( CPU 核数 × 4 , 32 )

然后配套三条铁律：

MaxIdleConns ≈ MaxOpenConns ÷ 2
ConnMaxLifetime = 1 ~ 10 分钟
集群总连接数 ≤ MySQL max_connections × 70%

这四条合起来，基本不会出事。

为什么这个公式”稳”#

1️⃣ CPU × 4 是现实上限，不是理论极限#

同一时刻：

真正执行 SQL 的线程 ≈ CPU 核数
多出来的连接只是在等待锁、IO 或调度

×4 已经是：IO 等待、网络抖动、偶发慢查询全部算进去后的 宽松冗余。超过这个数，收益快速递减。

2️⃣ 32 是经验性的”自保上限”#

不管你 16 核还是 64 核：后端服务极少需要 >32 个 DB 连接。超过 32，问题往往不在”连接不够”。

这是防止”硬件很好 → 连接无限膨胀”的刹车片。就像给跑车装限速器，不是为了让你开不快，而是为了让你别开太快。

3️⃣ Idle 连接不是越多越好#

Idle ≈ Open / 2 的含义是：

足够应对突发请求
又不会让 DB 长期背着无用连接

对连接重建成本和资源占用取得平衡。

4️⃣ 生命周期不是性能参数，是健康参数#

ConnMaxLifetime 的作用不是快，而是 防老化：

避免 MySQL / NAT / LB 偷偷断连接
让连接的内存状态周期性归零
减少”跑几天就慢”的玄学问题

把公式翻译成一句人话#

“每个应用实例，用 CPU 能真实跑得动的连接数，再乘一点容错；所有实例加起来，永远别把 MySQL 撑满。“

一个完整的例子#

应用实例：8 核
MySQL：max_connections = 500
应用实例数：10

单实例：

MaxOpenConns = min(8 × 4, 32) = 32
MaxIdleConns = 16

集群校验：

10 × 32 = 320 < 500 × 0.7 = 350 ✅

这是一个 工程上舒服 的状态。

什么时候这个公式不适用？#

你可以当成”警告灯”：

超高并发 OLTP（支付、撮合）
大量慢查询 / 报表
长事务（秒级）
单请求多次串行 DB 访问

这时该做的是：拆查询、上只读实例、异步化、分库分表，而不是把 MaxOpenConns 往上拉。

最后一句压箱底的话：连接池的正确目标不是”把并发顶住”，而是”把数据库保护住”。这个公式做的正是这件事。在大多数系统里，它不是最激进的，但几乎总是最安全的。

七、实战案例：200人后台管理系统怎么配？#

对一个 最多 200 人使用的后台管理系统（典型：CRUD、多列表、偶发导出），单 MySQL 实例 + 单应用实例 时：

MaxOpenConns：5 ~ 10
MaxIdleConns：2 ~ 5
ConnMaxLifetime：5 ~ 10 分钟

如果是 2–3 个应用实例：

MaxOpenConns：3 ~ 6 / 实例
MaxIdleConns：1 ~ 3 / 实例

是的，看起来非常小，这是 刻意的。

为什么 200 人 ≠ 200 个连接#

这是后台系统最容易被高估的地方。

1️⃣ 200 人的真实并发极低#

后台管理系统的现实画像是：

同时在线：可能 50–100
同时点按钮的：10–20
同时打到 DB 的：5–10

人类不是压测工具。大部分时间在看屏幕、想事情、切页面、喝水。这意味着：真实 DB 并发通常 < 10。

2️⃣ 后台 SQL 的”占用时间”很短#

后台系统通常是：

单表 / 少量 join
强索引
读多写少
无长事务（如果有，那是 bug）

一次查询常见：5–20 ms，连接会被非常快地归还给池子。

3️⃣ 小连接池反而更安全#

后台系统最怕的不是”慢一点”，而是：

某个列表页全表扫描
某次导出跑了 30 秒
某个误操作触发 N 次写

小连接池的效果是：

问题请求被限在少量连接里
其他请求还能活着
MySQL 不会被瞬间压垮

这是”隔离”，不是”抠门”。就像防火墙，不是为了让你上网慢，而是为了让你不被烧掉。

什么时候需要调大？#

只有在你 明确观测到：

连接池 wait 时间明显
MySQL Threads_running 很低
SQL 本身已经确认没问题

才考虑从 8 → 12，而不是 8 → 50。

最后一个略带哲学意味的事实：后台系统不是给”并发”用的，是给”人”用的。人类的操作节奏，天然就是最好的限流器。

八、最后的总结#

连接池配置的本质，是在三个维度上做权衡：

性能 vs 稳定性：更多连接 = 更高并发，但更不稳定
延迟 vs 成本：更多 Idle 连接 = 更低延迟，但更高资源占用
短期 vs 长期：长连接 = 更快启动，但可能老化失效

记住那个通用公式：

1
单实例 MySQL 最大连接数 ≈ min( CPU 核数 × 4 , 32 )
2
MaxIdleConns ≈ MaxOpenConns ÷ 2
3
ConnMaxLifetime = 1 ~ 10 分钟
4
集群总连接数 ≤ MySQL max_connections × 70%

这不是最激进的配置，但几乎总是最安全的。在大多数系统里，它能让你的数据库活得久一点，让你睡得安稳一点。

毕竟，连接池的正确目标不是”把并发顶住”，而是”把数据库保护住”。理解这一点，你就已经超越了 90% 的开发者。

世界的奇妙之处在于：数据库看起来像一个并发系统，实际上是一个被精心约束的顺序机器。理解这一点，连接池就不再是”参数调优”，而是系统设计的一部分。

Golang 并发控制：从 WaitGroup 到 errgroup 的深度实践与避坑指南

Fri, 06 Feb 2026 00:00:00 GMT

Golang 并发控制：从 WaitGroup 到 errgroup 的深度实践与避坑指南#

在 Golang 的业务开发中，如果你还在用串行方式请求 A、B、C、D 四个不相关的接口，那你的程序性能可能和树懒没什么区别。今天我们聊聊如何从原始的 WaitGroup 进化到现代化的 errgroup，让你的并发代码从”包工头”升级为”精英主管”。

1. 核心执行逻辑：一人报错，全家收工#

很多同学搞不清楚 errgroup 的 cancel 到底是什么时候触发的。看下面这张图就秒懂了：

1
    +-------------------------------------------------------+
2
    | Main Goroutine (g, ctx := errgroup.WithContext)       |
3
    +-------------------------------------------------------+
4
               |                |                |
5
        g.Go(Func A)     g.Go(Func B)     g.Go(Func C)
6
               |                |                |
7
               |          [ B 报错返回 ]           |
8
               |                |                |
9
               |         自动调用 cancel()         |
10
               |<---------------|--------------->|
11
        [ A 感知 ctx.Done ]              [ C 感知 ctx.Done ]
12
        [ 提前退出 ]                      [ 提前退出 ]
13
               |                |                |
14
    +-------------------------------------------------------+
15
    | g.Wait() 立即接收到第一个非空 error 并返回              |
16
    +-------------------------------------------------------+

显示更多显示更少

执行流程说明：

主 goroutine 通过 errgroup.WithContext 创建 errgroup 实例和 context
通过 g.Go() 启动多个子 goroutine
任意一个 goroutine 返回非空 error 时，自动触发 cancel()
其他 goroutine 通过 ctx.Done() 感知取消信号并优雅退出
g.Wait() 返回第一个非空 error

关键点： cancel() 是自动调用的，你不需要手动触发。这就是 errgroup 的魔法所在——它像个贴心的管家，一旦发现有人出事，立马通知所有人撤退。

2. 缘起：为什么不推荐原生 WaitGroup？#

想象一下，你负责一个”大杂烩”接口，需要同时查询：用户信息、订单记录、优惠券。

方案对比#

方案	执行方式	耗时	问题
方案 A	串行执行	所有接口总和	性能极差，用户体验堪忧
方案 B	原生 WaitGroup	最慢接口耗时	错误难捕捉、生命周期失控

WaitGroup 的痛点#

使用原生 WaitGroup 时，你会遇到以下问题：

错误难捕捉：其中一个崩了，你得开 channel 费劲地接住 error，就像在暴风雨中接住一片雪花
生命周期失控：如果 A 出错了，B 和 C 还在傻跑，浪费服务器资源，就像三个员工在办公室里加班，其实老板早就下班了

代码示例对比：

1
// WaitGroup 的痛苦写法
2
var wg sync.WaitGroup
3
errChan := make(chan error, 3)
4

5
wg.Add(3)
6
go func() {
7
    defer wg.Done()
8
    if err := callA(); err != nil {
9
        errChan <- err
10
    }
11
}()
12
// ... 重复 3 次
13

14
wg.Wait()
15
close(errChan)
16
for err := range errChan {
17
    // 处理错误
18
}
19

20
// errgroup 的优雅写法
21
g, ctx := errgroup.WithContext(context.Background())
22
g.Go(func() error {
23
    return callA()
24
})
25
// ... 重复 3 次
26

27
if err := g.Wait(); err != nil {
28
    // 处理错误
29
}

显示更多显示更少

看到区别了吗？errgroup 让你的代码从”写满注释的意大利面条”变成了”优雅的法式大餐”。

3. errgroup vs WaitGroup：从”包工头”到”精英主管”#

如果说 sync.WaitGroup 是个只会数数的包工头，那 errgroup 就是个精英主管：

核心优势#

共同进退：只要一人报错，大家一起收工，避免资源浪费
错误收集：自动帮你保存第一个返回的非空错误，不用自己写一堆 channel 逻辑
资源受控：自带 SetLimit 限流，防止把下游打挂，就像给服务器装了个”防超载保护器”

重构清单#

从 WaitGroup 迁移到 errgroup 的关键步骤：

1
// 1. 初始化（替代 sync.WaitGroup{}）
2
g, ctx := errgroup.WithContext(ctx)
3

4
// 2. 启动任务（替代 wg.Add(1) + go func()）
5
g.Go(func() error {
6
    // 你的业务逻辑
7
    return nil
8
})
9

10
// 3. 等待完成（替代 wg.Wait()）
11
if err := g.Wait(); err != nil {
12
    // 处理错误
13
}

迁移检查清单：

替换 sync.WaitGroup 为 errgroup.WithContext
将 wg.Add(1) 和 wg.Done() 替换为 g.Go()
将错误 channel 替换为 g.Wait() 返回值
确保所有子 goroutine 使用同一个 context
添加 ctx.Done() 检查以支持优雅退出

4. 硬核进阶：g.SetLimit 与 g.TryGo#

4.1 g.SetLimit(n)：控制并发上限#

别把服务器当驴使！合理的 SetLimit 应该参考公式：

1
N = CPU核心数 × (1 + 等待时间 / 计算时间)

这个公式来自《计算机程序设计艺术》，是并发控制的黄金法则。

使用示例：

1
g.SetLimit(10) // 最多同时运行 10 个 goroutine

实战场景： 假设你要处理 1000 个用户的批量操作，每个操作需要调用外部 API。如果不设置 SetLimit，你的程序会瞬间创建 1000 个 goroutine，可能导致：

内存爆炸
网络连接耗尽
下游服务被打挂（对方可能会拉黑你）

1
// 错误示范：无限制并发
2
for _, user := range users {
3
    g.Go(func() error {
4
        return callExternalAPI(user)
5
    })
6
}
7

8
// 正确示范：设置合理限流
9
g.SetLimit(50) // 根据下游服务承受能力调整
10
for _, user := range users {
11
    g.Go(func() error {
12
        return callExternalAPI(user)
13
    })
14
}

4.2 g.TryGo：职场试探学#

TryGo 就像是问女神：“明天有空吗？” 如果女神（Limit 满了）说没空，你立马执行 fallback（降级方案），绝不舔着脸在那等。

使用示例：

1
g.SetLimit(10)
2

3
// 尝试开启协程，如果并发已满则立即返回 false
4
if !g.TryGo(func() error {
5
    return callHeavyRPC(ctx)
6
}) {
7
    // 没位子了，走备选方案（如走缓存或返回默认值）
8
    return fallback()
9
}

TryGo 的优势：

非阻塞操作：不会等待，立即返回结果
可以立即执行降级策略：避免用户等待超时
防止资源耗尽导致的雪崩：在系统高负载时自动降级

实战场景： 在秒杀系统中，当并发请求超过系统承载能力时，使用 TryGo 可以立即返回”系统繁忙”，而不是让用户一直等待，最终超时。

1
func handleSeckillRequest(ctx context.Context, userID string) error {
2
    g.SetLimit(1000) // 系统最大并发处理能力
3

4
    if !g.TryGo(func() error {
5
        return processSeckill(ctx, userID)
6
    }) {
7
        return errors.New("系统繁忙，请稍后重试")
8
    }
9

10
    return nil
11
}

5. 完整 Demo：竞争执行 (Race Execution)#

这段代码演示了利用 errgroup 实现”任一成功/失败即取消其他任务”的硬核操作。

5.1 代码实现#

1
package main
2

3
import (
4
    "context"
5
    "errors"
6
    "fmt"
7
    "time"
8
    "golang.org/x/sync/errgroup"
9
)
10

11
func SearchData(ctx context.Context, name string, delay time.Duration, willFail bool) (string, error) {
12
    fmt.Printf("🚀 任务 [%s] 开始执行...\n", name)
13
    select {
14
    case <-time.After(delay):
15
        if willFail {
16
            return "", errors.New(name + " 发生故障")
17
        }
18
        return name + " 获取成功", nil
19
    case <-ctx.Done():
20
        fmt.Printf("⏹️ 任务 [%s] 收到取消信号，优雅退出。\n", name)
21
        return "", ctx.Err()
22
    }
23
}
24

25
func main() {
26
    g, ctx := errgroup.WithContext(context.Background())
27
    resultChan := make(chan string, 1) // 缓冲为 1，防止发送者阻塞
28

29
    tasks := []struct {
30
        n string
31
        d time.Duration
32
        f bool
33
    }{
34
        {"Service-A", 3 * time.Second, false},
35
        {"Service-B", 1 * time.Second, true}, // 它最快且报错，会触发全局 cancel
36
        {"Service-C", 5 * time.Second, false},
37
    }
38

39
    for _, t := range tasks {
40
        g.Go(func() error {
41
            res, err := SearchData(ctx, t.n, t.d, t.f)
42
            if err == nil {
43
                select {
44
                case resultChan <- res:
45
                default:
46
                }
47
            }
48
            return err
49
        })
50
    }
51

52
    go func() {
53
        if err := g.Wait(); err != nil {
54
            fmt.Printf("\n📢 Wait() 最终捕获错误: %v\n", err)
55
        }
56
        close(resultChan)
57
    }()
58

59
    if finalRes, ok := <-resultChan; ok {
60
        fmt.Printf("\n🏆 拿到结果: %s\n", finalRes)
61
    } else {
62
        fmt.Println("\n💀 任务全部失败或被取消。")
63
    }
64
}

显示更多显示更少

5.2 代码解析#

关键点说明：

Channel 缓冲：resultChan 缓冲为 1，防止发送者阻塞。如果缓冲为 0，当没有接收者时，发送者会永远阻塞。
优雅退出：通过 ctx.Done() 监听取消信号，确保 goroutine 能够及时退出，避免资源泄漏。
错误传播：g.Wait() 返回第一个非空 error，这是 errgroup 的核心特性。

执行流程：

Service-B 最快执行（1秒）且报错
触发全局 cancel()，取消其他任务
Service-A 和 Service-C 收到取消信号后优雅退出
g.Wait() 返回 Service-B 的错误

输出示例：

1
🚀 任务 [Service-A] 开始执行...
2
🚀 任务 [Service-B] 开始执行...
3
🚀 任务 [Service-C] 开始执行...
4
⏹️ 任务 [Service-A] 收到取消信号，优雅退出。
5
⏹️ 任务 [Service-C] 收到取消信号，优雅退出。
6

7
📢 Wait() 最终捕获错误: Service-B 发生故障
8

9
💀 任务全部失败或被取消。

6. 最佳实践总结#

6.1 使用建议#

场景	推荐方案	说明
简单并发等待	`sync.WaitGroup`	不需要错误处理时，比如批量日志处理
需要错误传播	`errgroup`	自动收集第一个错误，适合 API 聚合场景
需要并发限流	`errgroup.SetLimit`	防止资源耗尽，适合批量处理外部请求
需要降级策略	`errgroup.TryGo`	非阻塞，可立即降级，适合高并发场景

6.2 常见陷阱#

陷阱 1：Context 传递不一致#

1
// 错误示范
2
g, ctx := errgroup.WithContext(context.Background())
3
g.Go(func() error {
4
    return process(context.Background()) // 使用新的 context，无法感知取消
5
})
6

7
// 正确示范
8
g, ctx := errgroup.WithContext(context.Background())
9
g.Go(func() error {
10
    return process(ctx) // 使用同一个 context
11
})

陷阱 2：Channel 阻塞#

1
// 错误示范
2
resultChan := make(chan string) // 无缓冲
3
g.Go(func() error {
4
    resultChan <- "result" // 如果没有接收者，会永远阻塞
5
    return nil
6
})
7

8
// 正确示范
9
resultChan := make(chan string, 1) // 带缓冲
10
g.Go(func() error {
11
    resultChan <- "result"
12
    return nil
13
})

陷阱 3：资源泄漏#

1
// 错误示范：没有检查 ctx.Done()
2
g.Go(func() error {
3
    for {
4
        // 无限循环，即使 context 被取消也不会退出
5
        doSomething()
6
    }
7
})
8

9
// 正确示范：检查 ctx.Done()
10
g.Go(func() error {
11
    for {
12
        select {
13
        case <-ctx.Done():
14
            return ctx.Err()
15
        default:
16
            doSomething()
17
        }
18
    }
19
})

显示更多显示更少

6.3 性能优化建议#

合理设置 SetLimit：根据系统资源和下游服务承受能力设置，避免过度并发
使用 TryGo 实现非阻塞降级：在高并发场景下，及时降级比一直等待更重要
监控 goroutine 数量：使用 runtime.NumGoroutine() 监控，防止泄漏
合理使用 context 超时控制：设置合理的超时时间，避免 goroutine 长时间阻塞

性能对比：

1
// 场景：处理 1000 个外部 API 请求
2

3
// 方案 A：无限制并发
4
// 耗时：~1 秒（最快）
5
// 问题：可能导致下游服务崩溃，内存占用高
6

7
// 方案 B：SetLimit(100)
8
// 耗时：~10 秒
9
// 优势：稳定，不会打挂下游服务
10

11
// 方案 C：SetLimit(100) + TryGo + 降级
12
// 耗时：~10 秒
13
// 优势：稳定 + 用户体验好（立即返回降级结果）

7. 实战应用场景#

场景 1：微服务聚合#

1
func GetUserInfo(ctx context.Context, userID string) (*UserInfo, error) {
2
    g, ctx := errgroup.WithContext(ctx)
3
    var info UserInfo
4

5
    g.Go(func() error {
6
        var err error
7
        info.Profile, err = getProfile(ctx, userID)
8
        return err
9
    })
10

11
    g.Go(func() error {
12
        var err error
13
        info.Orders, err = getOrders(ctx, userID)
14
        return err
15
    })
16

17
    g.Go(func() error {
18
        var err error
19
        info.Coupons, err = getCoupons(ctx, userID)
20
        return err
21
    })
22

23
    if err := g.Wait(); err != nil {
24
        return nil, err
25
    }
26

27
    return &info, nil
28
}

显示更多显示更少

场景 2：批量数据处理#

1
func ProcessBatch(ctx context.Context, items []Item) error {
2
    g, ctx := errgroup.WithContext(ctx)
3
    g.SetLimit(50) // 控制并发数
4

5
    for _, item := range items {
6
        g.Go(func() error {
7
            return processItem(ctx, item)
8
        })
9
    }
10

11
    return g.Wait()
12
}

场景 3：健康检查#

1
func HealthCheck(ctx context.Context) error {
2
    g, ctx := errgroup.WithContext(ctx)
3
    g.SetLimit(5)
4

5
    services := []string{"db", "redis", "mq", "cache", "api"}
6

7
    for _, svc := range services {
8
        svc := svc
9
        g.Go(func() error {
10
            return checkService(ctx, svc)
11
        })
12
    }
13

14
    return g.Wait()
15
}

显示更多显示更少

8. 参考资源#

总结#

errgroup 是 Go 并发编程的利器，它不仅解决了 WaitGroup 的痛点，还提供了更强大的错误处理和资源控制能力。从 WaitGroup 到 errgroup，不仅是工具的升级，更是思维方式的转变——从”只会数数的包工头”到”懂得管理的精英主管”。

掌握 errgroup，让你的并发代码更优雅、更健壮、更高效。记住，好的并发代码不仅要快，还要稳。就像人生一样，不仅要追求速度，更要懂得何时停下。

最后送给大家一句话： “并发编程就像谈恋爱，既要懂得放手（context cancel），又要懂得坚持（error handling），最重要的是要懂得控制节奏（SetLimit）。”

相关阅读：

Shuai's Blog

MySQL连接池配置指南：别让数据库被你的"慷慨"压垮

一句话核心观点#

一、你在给谁配？先想清楚这三个对象#

二、MySQL 侧的硬约束（地心引力）#

1. max_connections 是硬天花板#

2. MySQL 不擅长”超高并发短查询”#

三、应用侧：一个实例该开多少连接？#

1. 先看你的应用模型#

2. 一个非常实用的估算公式（工程经验）#

3. 不要把”并发数”直接映射成”连接数”#

四、集群视角：真正容易翻车的地方#

五、连接池三个核心参数详解#

1. MaxOpenConns —— 连接池的”硬天花板”#

2. MaxIdleConns —— 连接的”保温箱”#

3. ConnMaxLifetime —— 连接的”寿命上限”#

4. 把三者放在同一条时间线上#

5. 三个参数的”分工关系”#

6. 配置不当的后果#

只调 MaxOpenConns，会怎样？#

Idle 配太大，会怎样？#

不设 ConnMaxLifetime，会怎样？#

最后一句工程真相#

六、通用公式：一条能直接上线的经验法则#

通用结论版（先记住这一行）#

为什么这个公式”稳”#

1️⃣ CPU × 4 是现实上限，不是理论极限#

2️⃣ 32 是经验性的”自保上限”#

3️⃣ Idle 连接不是越多越好#

4️⃣ 生命周期不是性能参数，是健康参数#

把公式翻译成一句人话#

一个完整的例子#

什么时候这个公式不适用？#

七、实战案例：200人后台管理系统怎么配？#

为什么 200 人 ≠ 200 个连接#

1️⃣ 200 人的真实并发极低#

2️⃣ 后台 SQL 的”占用时间”很短#

3️⃣ 小连接池反而更安全#

推荐你顺手配的 Go 示例#

什么时候需要调大？#

八、最后的总结#

Golang 并发控制：从 WaitGroup 到 errgroup 的深度实践与避坑指南

Golang 并发控制：从 WaitGroup 到 errgroup 的深度实践与避坑指南#

1. 核心执行逻辑：一人报错，全家收工#

2. 缘起：为什么不推荐原生 WaitGroup？#

方案对比#

WaitGroup 的痛点#

3. errgroup vs WaitGroup：从”包工头”到”精英主管”#

核心优势#

重构清单#

4. 硬核进阶：g.SetLimit 与 g.TryGo#

4.1 g.SetLimit(n)：控制并发上限#

4.2 g.TryGo：职场试探学#

5. 完整 Demo：竞争执行 (Race Execution)#

5.1 代码实现#

5.2 代码解析#

6. 最佳实践总结#

6.1 使用建议#

6.2 常见陷阱#

陷阱 1：Context 传递不一致#

陷阱 2：Channel 阻塞#

陷阱 3：资源泄漏#

6.3 性能优化建议#

7. 实战应用场景#

场景 1：微服务聚合#

场景 2：批量数据处理#

场景 3：健康检查#

8. 参考资源#

总结#