记一次 GORM 开启 PrepareStmt 导致的内存泄漏

Linux

发布日期: 2023-09-12

文章字数: 1.2k

阅读时长: 4 分钟

0. 前言

某天线上某个高并发的服务，腾讯云内存指标监控报警
Go 进程的内存指标像坐了火箭一样一路飙升，最终频繁触发 OOM 被强制杀掉。

与此同时MYSQL大量报错

Error 1461: Can't create more than max_prepared_stmt_count statements (current value: 16382)

本以为是一次普通的连接池泄漏，或者是某段逻辑没释放连接，但经过一轮 pprof 深度排查后，发现罪魁祸首竟然是一个为了“优化性能”而开启的配置：PrepareStmt: true。

今天就来彻底拆解一下 GORM 预编译缓存（PrepareStmt） 遇到 SQL 字符串拼接时，是如何联手把 Go 服务和 MySQL 一起送进 ICU 的。

1. 案发现场：那行被写烂的 SQL

在排查代码时，我们在一个高频调用的动态筛选接口里，因为查询涉及复杂的参数和筛选和多表联查
使用了类似下面这样的原生 SQL 编写方式：

// 错误示范：为了偷懒或处理复杂的动态条件，直接用 Fmt 拼接了变量
func GetOrderList(status string, userID int64) ([]Order, error) {
    var orders []Order
    sql := fmt.Sprintf("SELECT * FROM orders WHERE user_id = %d", userID)
    
    if status != "" {
        sql += fmt.Sprintf(" AND status = '%s'", status)
    }
    
    err := db.Raw(sql).Scan(&orders).Error
    return orders, err
}

而在全局初始化 GORM 的地方，为了追求所谓的“极致性能”，前人开启了全局预编译：

db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{
    PrepareStmt: true, // 开启全局预编译语句缓存
})

就是这两个看似不起眼的组合，在线上真实流量下，瞬间演变成了内存杀手。

2. 深度剖析：缓存是怎么变成“毒药”的？

想要知道为什么会爆，得先看明白 GORM 开启 PrepareStmt: true 后底层的运行逻辑。

正常的预编译逻辑（参数化查询）
如果我们在代码里规规矩矩地使用问号占位符（?）：
db.Raw(“SELECT * FROM orders WHERE user_id = ?”, userID)

GORM 拿到这个 SQL，会去它内部的缓存 Map 里查找 Key：”SELECT * FROM orders WHERE user_id = ?”。

第一次找不到，GORM 向 MySQL 发送 COM_STMT_PREPARE 命令。

MySQL 服务端编译该 SQL，返回一个 STMT_ID。

GORM 把这个 STMT_ID 存在本地缓存中。

下次不管 userID 传什么，SQL 字符串骨架没变，永远命中同一个缓存，直接走 EXECUTE 传值，既省了 MySQL 编译网络开销，又安全。

畸形的预编译逻辑（字符串拼接）
一旦代码里用了 fmt.Sprintf，传过来的 SQL 字符串就变成了：

第一次请求：SELECT * FROM orders WHERE user_id = 1001

第二次请求：SELECT * FROM orders WHERE user_id = 1002

此时，GORM 内部严格的 Map 匹配机制傻眼了：在它眼里，这是两条截然不同的全新 SQL。

于是，灾难开始扩散：

Go 进程内部：GORM 认为这是一条新 SQL，疯狂地往本地缓存（LRU 缓存）里塞入新的 Key 和 Stmt 对象。因为并发极高，短时间内大量未释放的对象把 Go 堆内存直接撑爆（OOM）。

MySQL 服务端：GORM 每次都向 MySQL 申请预编译，MySQL 乖乖地为每一个拼接出来的 SQL 分配内存、生成执行计划并绑定 STMT_ID。

当这个数字突破 MySQL 全局上限 max_prepared_stmt_count（默认 16382）时，MySQL 就会拒绝后续所有的预编译请求，整个集群直接瘫痪。

3. 彻底修复与最佳实践

针对这种复杂、动态的 SQL 场景，有非常标准的规范写法，绝对不要图一时痛快去拼字符串(拼接一时爽，头发火葬场。

方案一：动态骨架拼接 + 参数数组（最标准）
如果 SQL 结构必须动态生成，只拼骨架，不拼数据。


func GetOrderListSafe(status string, userID int64) ([]Order, error) {
    var orders []Order
    
    // 1. 固定的 SQL 骨架
    sql := "SELECT * FROM orders WHERE user_id = ?"
    var args []interface{}
    args = append(args, userID)
    
    // 2. 动态拼接占位符，而不是具体的值
    if status != "" {
        sql += " AND status = ?"
        args = append(args, status)
    }
    
    // 3. 将参数一同传给 GORM
    err := db.Raw(sql, args...).Scan(&orders).Error
    return orders, err
}