GORM的Limit+Offset分页在日志系统中数据超10万后性能骤降，因数据库需扫描并丢弃前N行；应改用游标分页，要求排序字段单调非空且有匹配索引、游标值来自当前页末条记录、首次查21条判断是否有下一页。
大规模日志流转系统里，GORM 的 Limit + Offset 分页在数据量超 10 万后基本不可用——不是代码写错了，是 MySQL/PostgreSQL 执行机制决定的：它必须扫描并丢弃前 N 行，而不是跳过。日志场景下，单表千万级很常见，第 5000 页（OFFSET 99999）查询可能耗时 2.3 秒、CPU 拉满、连接堆积。真要稳，得切游标分页，且排序字段必须带索引、前端透传 last_id 或时间戳，不能转页码。
为什么日志系统里 Offset 分页会突然崩掉
日志表通常按时间递增写入，但查询时往往要翻到“昨天凌晨的某批错误”，这就导致 Offset 值越来越大。一旦 OFFSET 超过 10 万，数据库引擎无法直接定位，只能从 B+ 树根节点开始逐层遍历、排序、丢弃——哪怕你只查 20 条，也得先读 10 万行。
- 常见错误现象：
db.Offset(499999).Limit(20)在压测中触发MySQL Error 1205: Deadlock found或连接超时；同一页刷新两次，返回记录顺序不一致甚至漏掉某条 - 即使给
created_at加了索引，OFFSET仍需在索引树里跳转，无法像WHERE id > ?那样直接定位叶子节点 - 日志写入高并发，MVCC 版本不一致会导致同一
OFFSET查询返回不同快照，结果不可重现 -
Count(*)全表统计在日志表上尤其危险：没有WHERE条件时，InnoDB 得扫聚簇索引；加了WHERE level = 'error'还没走索引，就更慢
游标分页必须满足的三个硬条件
游标分页不是换个写法就行，它依赖确定的排序语义和索引结构。日志系统里最稳妥的是 id ASC 或 created_at DESC, id DESC，但每一步都容易出错。
- 首排序字段必须单调、非空、有索引：优先用自增
id；若用created_at，必须设为DATETIME(6)或BIGINT时间戳，避免毫秒级重复 - 多字段排序时，索引顺序必须严格匹配：比如
ORDER BY created_at DESC, id DESC，索引就得是INDEX idx_time_id (created_at, id)，反过来或缺字段都会失效 - 游标值必须来自当前页最后一条记录：前端传
last_id=12345，后端查WHERE id > 12345 ORDER BY id ASC LIMIT 20；绝不能用第一页第一条的id当游标，否则会跳过中间数据 - 首次请求不带游标，查
db.Order("id ASC").Limit(21).Find(&logs)（多查 1 条），有第 21 条就说明“还有下一页”
GORM 中 Count 总数怎么查才既准又不拖垮 DB
日志系统前端常要显示“共 XXX 条”，但查总数这一步最容易成为性能瓶颈。关键是：别让 Count() 和主查询共享同一个 *gorm.DB 实例，也别信任何自动继承条件的封装。
- 简单场景（无 JOIN）：
db.Session(&gorm.Session{NewDB: true}).Model(&Log{}).Where("level = ?", "error").Count(&total)——NewDB: true确保隔离，不复用原链的Limit/Offset - 复杂场景（含
Joins或模糊搜索）：手写子查询，例如db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM logs WHERE level = ? AND message LIKE ?) AS t", "error", "%timeout%").Scan(&total) - 如果 UI 允许，直接去掉总数：查
pageSize + 1条，有第pageSize + 1条就返回has_next: true，省一次全表扫描，QPS 能翻倍 - 缓存总数只适用于低频变更的日志分类统计（如“今日 error 数”），不能用于原始日志列表——日志写入太频繁，缓存极易过期或不准
日志分页最容易被忽略的稳定性细节
游标分页看似简单，但在日志这种高吞吐、高并发、带时间精度的场景下，一个字符的处理偏差就会导致数据错乱或查询失败。
- 前端传的游标值（如
last_created_at）必须用base64.RawURLEncoding.DecodeString解码，防止 URL 中的+或/被 HTTP Server 误解析成空格或路径分隔符 -
created_at字段必须统一时区：入库用 UTC，查询也用 UTC，避免前端传东八区时间戳，后端拿去比对时区混乱 - 不要用
time.Now().Format("2006-01-02 15:04:05")拼 SQL 条件——格式化会丢失纳秒精度，且易受 locale 影响；直接传int64时间戳或使用time.Time变量交由 GORM 处理 - 日志表建议分区：按天或按小时建
PARTITION BY RANGE (TO_DAYS(created_at))，能极大降低单次查询扫描范围，配合游标效果更佳
