高并发下gorm查询变慢主因是连接池未调优、n+1未解决、索引缺失；需设setmaxopenconns为数据库max_connections的60%～80%、setmaxidleconns为1/2～2/3、setconnmaxlifetime为2～5分钟，并配db.ping()校验。
高并发下GORM数据库连接变慢，90%不是框架问题，而是连接池没调、N+1没破、索引没建——这三件事不做，加再多协程也卡在数据库上。
怎么调 *sql.DB 连接池参数才不爆 too many connections
GORM 本身不管理连接，它只是 database/sql 的包装层。默认配置在生产环境必然出事：
-
SetMaxOpenConns(0)：等于不限制，MySQL 服务端扛不住，连接数直接打满 -
SetMaxIdleConns(2)：空闲连接太少，每次并发请求都得新建连接，销毁开销大 -
SetConnMaxLifetime(0)：连接永不过期，MySQL 主动断连后 GORM 会不断重连，引发风暴
必须在 gorm.Open() 之后立刻拿到原生连接池并设置：
db, _ := gorm.Open(mysql.Open(dsn), &gorm.Config{})
sqlDB, _ := db.DB()
sqlDB.SetMaxOpenConns(100) // 按峰值 QPS × 平均耗时 / 1000 + 20% 缓冲估算
sqlDB.SetMaxIdleConns(20) // 避免频繁建连
sqlDB.SetConnMaxLifetime(time.Hour) // 防止 MySQL 主动断连导致重连
别忘了加 db.Ping() 校验连接是否可用，否则启动时可能静默失败。
为什么 Preload 在高并发下容易拖垮内存和连接
Preload("Orders") 看着省事，但默认会把每个用户的全部订单全量拉下来，字段越多、关联越深，内存和网络开销越大：
- 不加条件的
Preload= 全表扫描关联表，哪怕主表只查 10 条 - 多级嵌套如
Preload("Orders.Items")，若没限制字段，可能一次拉几十 MB 数据 -
Association方法（如user.Orders）是延迟加载，访问时才查，极易隐式触发 N+1
正确写法是带条件 + 字段精简：
db.Preload("Orders", func(db *gorm.DB) *gorm.DB {
return db.Where("status = ?", "paid").
Select("id, user_id, amount, created_at")
}).Find(&users)
更狠的优化：用 Joins + Select 替代嵌套结构体，字段可控、无反射开销、SQL 执行计划更稳定。
为什么游标分页比 OFFSET 更适合高并发列表
OFFSET 10000 LIMIT 20 在 MySQL 里不是跳指针，而是真实扫描前 10020 行再丢掉前 10000 条。并发写入时，还容易漏数据或重复：
- 游标必须基于单调字段，首选
id（自增主键），次选created_at DESC（注意精度，建议用datetime(3)或bigint时间戳） -
FindInBatches是读场景的批量游标方案，避免一次性加载海量数据 - 写入侧也要配合游标逻辑，比如按
id > last_id ORDER BY id LIMIT 100分批处理
游标本质是状态延续，不是位置偏移——这点一旦理解错，分页就永远有边界问题。
连接池参数、预加载控制、分页方式，这三处改动成本低，但效果立竿见影。最容易被忽略的是：调完参数不验证 db.Ping()，或者以为 Preload 加了就万事大吉，结果线上内存持续上涨却找不到源头。
