time-based分页更适合物联网时序数据分页，因其利用时间戳+ID游标避免OFFSET全表扫描，支持无状态分页且能应对乱序；需建(created_at,id)联合索引、显式Select字段、禁用QueryFields，并确保CreatedAt映射正确。
直接用 Offset/Limit 做物联网时序数据分页，在高偏移量下会严重拖慢查询、甚至拖垮数据库。这不是 GORM 的 bug，而是 MySQL/PostgreSQL 对 LIMIT 100000, 20 这类语句的天然执行缺陷——它仍要扫描前 10 万行。
为什么 time-based 分页比 offset/limit 更适合时序场景
物联网设备上报数据具有强时间单调性（时间戳严格递增或基本有序），且查询通常按“最近 N 条”“某段时间内”展开。这时用时间戳做游标（cursor-based pagination）能跳过全表扫描：
- 避免
OFFSET导致的索引失效和回表放大 - 天然支持无状态分页（前端只需传上一页最后一条的
created_at） - 即使有写入延迟或乱序，加
id二级排序即可保序 - GORM 支持原生拼接，无需手写 raw SQL
在 GORM 中实现安全的 time-based 分页
假设设备上报表结构为：
type DeviceMetric struct {
ID uint `gorm:"primaryKey"`
DeviceID string `gorm:"index"`
Value float64
CreatedAt time.Time `gorm:"index"`
}
推荐分页逻辑（含防乱序兜底）：
- 首次请求：不带游标，用
ORDER BY created_at DESC, id DESC LIMIT 20 - 后续请求：传上一页最后一条的
created_at和id，条件为：WHERE created_at - 必须确保
(created_at, id)有联合索引，否则性能无保障 - 不要用
Find(&list)直接查结构体，先用Count()获取总条数代价太高；如需总数，改用近似值或单独异步统计
警惕 GORM 的 QueryFields 和 Select 组合陷阱
开启 QueryFields: true 后，db.Find(&metrics) 会自动只查结构体中定义的字段——但若你用了嵌套结构体或匿名字段，GORM 可能漏掉 created_at 或 id，导致游标条件失效：
- 显式指定字段最稳妥：
db.Select("id", "device_id", "value", "created_at").Where(...).Order("created_at DESC, id DESC").Limit(20).Find(&metrics) - 禁用
QueryFields，靠Select精确控制，避免隐式行为干扰分页逻辑 - 对
CreatedAt字段务必确认其 GORM 标签是gorm:"column:created_at"，否则可能被映射成createdat导致 WHERE 条件不生效
高频写入下的游标一致性风险
设备端网络抖动可能导致同一批数据的时间戳集中在同一毫秒级，甚至逆序。仅靠 created_at 游标会漏数据或重复：
- 永远把
id作为第二排序和第二游标字段（主键自增 or ULID） - 避免用
updated_at做游标——它可能被业务逻辑反复更新，失去单调性 - 如果用分布式 ID（如 Snowflake），需确认其时间部分精度足够（至少毫秒），否则仍需 fallback 到
id - 测试时故意插入两条
created_at相同但id差 1 的记录，验证分页是否跳过或重复
真正难的不是写对第一条分页语句，而是让第 100 页、第 10000 页都返回确定且可复现的结果——这要求游标字段组合在任意写入压力下都保持全局唯一且有序。
