Limit+Offset分页必须避免，FindInBatches和基于时间戳/ID的游标分页才是可行解；因Offset需扫描丢弃大量数据导致延迟飙升、CPU/I/O过载，而日志查询本质是范围拉取，非真分页。
直接说结论：网络设备日志这类写多读少、数据量大、查询偏重“最新N条”或“按时间范围拉取”的场景，Limit+Offset分页必须避免，FindInBatches 和基于时间戳/ID的游标分页才是可行解。
为什么 Offset 分页在日志场景下会崩
网络设备日志动辄每天百万级写入，表里轻松积累千万行。一旦用 db.Offset(99900).Limit(100) 查第1000页，MySQL 就得扫描并丢弃前 99900 行——不是跳过索引位置，是真扫描、真排序、真丢弃。实际压测中，Offset 超过 5 万后，P95 延迟常突破 2s，且 CPU 和 I/O 持续飙高。
- 日志查询几乎不关心“第几页”，只关心“从某时间之后的最近100条”或“ID大于X的下一批”
-
ORDER BY created_at DESC+OFFSET无法利用created_at索引做高效范围扫描，优化器大概率走全表或临时文件排序 - 并发查不同页时，数据库连接池容易被慢查询占满，拖垮整个 API
用 FindInBatches 替代分页循环
FindInBatches 不是“帮你循环调用 Limit/Offset”，而是基于主键（默认 id）做游标推进。它天然适合流式拉取日志，尤其配合定时任务或长轮询消费。
- 必须显式指定排序：
db.Order("id ASC").FindInBatches(&logs, 1000, func(tx *gorm.DB, batch int) error { ... })，否则 GORM 会自动补ORDER BY id，但方向不可控 - 如果日志表主键不是自增整型（比如用了 UUID），
FindInBatches会失效——它底层依赖可比较、有顺序的主键值 - 每批处理完记得记录最后一条的
log.ID，作为下次调用的起点条件（需自行拼 WHERE） - 不要把它当“分页接口”直接暴露给前端；它是后端批量消费的工具，前端应走游标 API
更实用的方案：时间戳游标分页
网络日志几乎都有 created_at 字段，且写入时间基本单调递增。用时间戳做游标，语义清晰、索引友好、无需维护最大 ID 状态。
- 查询“最新100条”：
db.Where("created_at - 查询“上一页”（即更早的100条）：
db.Where("created_at - 务必给
created_at加联合索引，例如INDEX idx_created_device (created_at, device_id)，避免回表 - 注意 MySQL 的
DATETIME精度问题：如果日志密集写入（毫秒级同时间戳），单靠created_at可能漏数据或重复，建议补上id作为第二排序字段：Order("created_at DESC, id DESC")
别忽略写入侧对分页的影响
日志写入不优化，再好的分页也扛不住。GORM 默认逐条 Create，在高吞吐下会成为瓶颈。
- 改用
CreateInBatches：例如db.CreateInBatches(logs, 500)，生成单条多值 INSERT，吞吐可提升 5–10 倍 - 批次大小控制在 100–500：太小起不到摊销作用，太大易触发
max_allowed_packet或事务锁等待 - 必须手动包事务：
tx := db.Begin(); tx.CreateInBatches(...); tx.Commit()，否则某批失败会导致部分提交 - 如果日志量极大（>10 万条/秒），考虑绕过 GORM，直连
*sql.DB做Prepare+ 批量Exec，GORM 的 hook 和模型转换此时已是累赘
真正卡住人的往往不是语法怎么写，而是没想清楚：日志要不要永久保留？查的是“最新”还是“某时段”？下游系统能不能接受游标而非页码？这些业务判断，比选哪个 GORM 方法重要得多。
