使用Go协程结合GORM v1并发查询MySQL时遭遇1040连接数过多错误的问题排查与解决咨询

API 探路者

2026-4-28

刚好之前也踩过GORM v1并发连接的坑，给你梳理下这些问题的原因和解决方案：

为什么会出现MySQL 1040 "too many connections"错误？

这个错误本质是MySQL的活跃连接数达到了它配置的max_connections上限。结合你的场景，核心原因大概率是数据库连接池配置不合理或者连接没有被正确归还。

GORM v1底层依赖Go标准库的database/sql连接池，默认情况下，连接池的MaxOpenConns（最大打开连接数）是0——这意味着它会无限制创建新连接，直到触达MySQL的max_connections上限。当你同时启动10个协程执行查询时，如果连接池里没有空闲连接，就会新建连接；如果此时还有其他业务在占用连接，很容易就把MySQL的连接数打满。

每个Go协程是否会创建新的数据库连接？

答案是不一定，这完全取决于连接池的当前状态：

如果连接池里有空闲连接，协程会直接复用这个连接，不会新建；
如果没有空闲连接，但当前打开的连接数还没到MaxOpenConns的上限，就会新建一个连接；
如果已经到了上限，协程会进入等待状态，直到有连接被归还或者超时。

但如果你的代码存在连接泄漏（比如事务没调用Commit()/Rollback()，或者手动执行Raw()后没正确释放资源），连接会一直被占用，连接池不得不持续新建连接，最终触达MySQL的上限。

如何查看MySQL中的「实时连接」？

最直观的方式是执行这两个MySQL命令：

SHOW PROCESSLIST;：会列出当前所有的MySQL连接，包括每个连接的ID、用户、主机、数据库、状态（比如Sleep、Query）、正在执行的语句等，能一眼看到哪些连接在活跃，哪些在休眠；
SELECT * FROM information_schema.processlist;：这是更结构化的查询方式，支持过滤条件，比如你可以只查当前应用的连接：
```
SELECT * FROM information_schema.processlist WHERE USER = 'your_app_db_user';
```

这两个命令都能看到实时的连接情况，比SHOW STATUS的统计变量更直接。

如何正确实现数据库的并发查询？

结合你的场景，推荐这几个优化点：

合理配置连接池参数
GORM v1可以通过底层的sql.DB对象来配置连接池，限制最大连接数：

// 获取底层的sql.DB实例
sqlDB, err := DB.DB()
if err != nil {
    panic(err) // 或者根据业务处理错误
}
// 设置最大打开连接数：根据MySQL的max_connections和业务并发量调整，比如设为20
sqlDB.SetMaxOpenConns(20)
// 设置最大空闲连接数：一般小于等于MaxOpenConns，比如10
sqlDB.SetMaxIdleConns(10)
// 设置连接最大生命周期：避免连接长时间占用，比如1小时
sqlDB.SetConnMaxLifetime(time.Hour)

这样能从根源上限制连接池的连接数，不会无限制创建连接。

控制协程并发数
虽然现在是10组查询，但如果后续业务扩展，建议用信号量控制同时执行的协程数，避免一下子打满连接池。比如用带缓冲的通道实现：

import "sync"
import "time"

func main() {
    // 限制同时执行5个协程
    sem := make(chan struct{}, 5)
    var wg sync.WaitGroup

    // 把所有查询函数放到切片里遍历
    queryFuncs := []func(*gorm.DB){queryset1, queryset2, queryset3, /*...*/ queryset10}
    for _, f := range queryFuncs {
        wg.Add(1)
        sem <- struct{}{} // 获取信号量
        go func(queryFunc func(*gorm.DB)) {
            defer wg.Done()
            defer func() { <-sem }() // 释放信号量
            queryFunc(DB)
        }(f)
    }
    wg.Wait()
}

确保连接正确归还
- 如果使用了事务，一定要在最后调用Commit()或Rollback()，哪怕出现错误（可以用defer来保证）；
- 避免在查询后执行大量CPU密集型操作，应该先把查询结果读取出来，再释放连接（GORM的方法默认会在执行完后归还连接，但手动持有连接时要格外注意）。
排查连接泄漏
可以用SHOW PROCESSLIST查看长时间处于Sleep状态的连接，如果数量过多，可能是MaxIdleConns设置得太高，或者有连接没有被正确归还。另外，也可以通过sqlDB.Stats()获取连接池的统计信息，比如OpenConnections（当前打开的连接数）、IdleConnections（空闲连接数）等，来定位问题。

内容的提问来源于stack exchange，提问作者Niranjan Shetty