高并发下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主动断连导致重连
怎么避免Preload引发的内存爆炸和N+1
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时间戳） - 前端传来的
last_id必须校验类型和范围，非法值直接400，别默默转成0 - 游标分页不能直接
Count总数，要单独走db.Model(&User{}).Where(...).Count(&total)
实操写法：
// 首次请求
db.Order("id ASC").Limit(21).Find(&users)
// 后续请求（lastID来自上一页最后一条的id）
db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users)
最容易被忽略的底层地基：索引和字段精简
所有优化的前提是：WHERE字段、ORDER BY字段、JOIN ON字段必须有索引。没有status索引，Limit再早加也没用；没有ORDER BY id索引，游标分页照样扫全表。
- 模型定义只声明业务真正需要的字段，用
gorm:"-"忽略不用列 - 禁用自动复数表名：
gorm.NamingStrategy{SingularTable: true}，减少反射开销 - 高频查询字段必须建联合索引，比如
WHERE status = ? AND deleted_at IS NULL ORDER BY id，对应索引应为(status, deleted_at, id)
连接池、预加载、分页策略这些都能调，但索引一旦缺位，所有上层优化都会失效——它不像代码能热更新，改索引要锁表、要评估影响，必须在上线前就配好。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
