GORM执行数次查询后性能骤降问题排查求助

核心原因推测 #

1. 查询计划“跑偏” #

PostgreSQL的查询计划器会缓存执行计划，但如果统计信息过时，或者遇到特殊场景（比如同一查询多次执行后，计划器突然放弃索引改用全表扫描），就会导致速度暴跌。尤其是你用的是%xxx%的ILIKE查询，如果建的是普通B-tree索引，这种索引根本无法加速前缀/后缀通配的模糊搜索——前几次快纯粹是因为查询结果或数据页在内存缓存里，后续缓存被清掉就会触发全表扫描，直接慢到5秒以上。

2. GORM连接上下文污染 #

如果你的dbHandler实例之前残留了未提交的事务、锁或者其他上下文状态，复用这个连接执行后续查询时，就可能出现异常延迟。比如某个Scopes（比如Paginate）里不小心开启了事务但没收尾，后续连接复用就会带着这个“脏”上下文跑查询。

3. 数据库缓存驱逐 #

虽然你说测试期间无其他流量，但PostgreSQL的共享缓冲区可能因为后台操作（比如autovacuum清理旧数据）把之前缓存的产品数据页给挤出去了，导致第5次查询需要重新从磁盘读取数据，速度骤降。而重新执行时数据又被加载回缓存，所以又变快。

具体解决步骤 #

1. 先确认索引是否真的能用 #

ILIKE '%xxx%'这种模糊搜索，普通B-tree索引完全无效，必须用PostgreSQL的trigram索引（依赖pg_trgm扩展）：

-- 先安装扩展（如果没装过）
CREATE EXTENSION IF NOT EXISTS pg_trgm;
-- 创建GIN索引（比GIST更快，适合大表）
CREATE INDEX idx_products_title_trgm ON products USING gin (title gin_trgm_ops);

如果之前建的是普通B-tree索引，直接删掉换成这个，再测试连续查询的速度。

2. 强制查询使用索引 #

如果确认索引正确，但计划器还是偶尔选错计划，可以在GORM里强制指定索引：

res := dbHandler.
    Scopes(query.Paginate(listRequest)).
    Where(where.Main, where.Values...).
    Order(orderBy).
    // 强制使用trigram索引
    Clauses(clause.Locking{ForceIndex: "idx_products_title_trgm"}).
    Find(rows)

同时可以在数据库里用EXPLAIN ANALYZE对比快/慢查询的执行计划，看是不是真的用了索引：

EXPLAIN ANALYZE SELECT * FROM products WHERE title ILIKE '%Warum Frauen alles besser wissen - und trotzdem alles falsch machen%' LIMIT 10;

3. 用干净的DB实例执行查询 #

避免连接上下文污染，每次查询都从主DB实例创建一个干净的子实例：

// 新建干净的DB实例，隔离之前的上下文
cleanDB := dbHandler.New()
res := cleanDB.
    Scopes(query.Paginate(listRequest)).
    Where(where.Main, where.Values...).
    Order(orderBy).
    Find(rows)

另外检查GORM的连接池配置，避免连接复用出现问题：

sqlDB, err := dbHandler.DB()
if err != nil {
    // 处理错误
}
// 根据服务器配置调整，比如最大打开连接数设为20
sqlDB.SetMaxOpenConns(20)
sqlDB.SetMaxIdleConns(10)
sqlDB.SetConnMaxLifetime(time.Hour)

4. 刷新数据库统计信息 #

PostgreSQL的查询计划依赖统计信息，过时的统计信息会导致计划器做出错误选择，手动刷新：

ANALYZE products;

5. 开启慢查询日志抓细节 #

修改PostgreSQL的postgresql.conf配置，开启慢查询日志：

log_min_duration_statement = 1000  # 记录耗时超过1秒的查询
log_statement = 'all'              # 可选，记录所有查询（方便排查）
log_line_prefix = '%t [%p]: [%c-%l] user=%u,db=%d,app=%a '  # 日志加上时间、进程等信息

重启PostgreSQL后，看慢查询日志里的执行计划和当时的数据库状态，就能精准定位问题。

内容的提问来源于stack exchange，提问作者Dubravko Petrovic