OFFSET分页在物联网设备历史表中会出问题，因其依赖行序而高频写入导致幻读、数据重复或丢失；同一毫秒多设备写入使created_at无法作为稳定游标，且深度偏移引发IO和CPU开销陡增。
物联网设备历史记录的分页不能直接套用普通业务表的 Limit/Offset 方式——时间范围不固定、写入高频、查询条件多变，硬分页容易拖垮数据库或漏数据。
为什么用 Offset 分页在设备历史表里会出问题
设备上报频率可能从秒级到分钟级不等，Offset 依赖行序，但新数据持续插入会导致“幻读”：用户翻到第 3 页时，第 1 页刚插入一批旧时间戳数据，后续页码整体偏移，同一条记录可能重复出现或直接消失。MySQL 的 ORDER BY created_at DESC, id DESC 也不能完全规避，因为同一毫秒可能有多个设备写入。
- 高频写入下，
OFFSET 10000实际要扫描前 10001 行，IO 和 CPU 开销陡增 - 没有全局唯一递增时间戳字段，仅靠
created_at无法做稳定游标 - 设备 ID + 时间组合查询很常见，但
WHERE device_id = ? AND created_at 若没覆盖索引，会全表扫描
推荐用基于游标的分页（Cursor-based Pagination）
核心是用上一页最后一条记录的排序键作为下一页起点，不依赖总条数和偏移量。对设备历史表，最稳的游标字段组合是：created_at + id（假设 id 是自增主键或时间有序 UUID）。
- 首次查询：按时间倒序取前 N 条，记录最后一条的
created_at和id - 后续查询：用
WHERE device_id = ? AND (created_at, id) ，注意括号内是复合比较，MySQL 8.0+ 和 PostgreSQL 原生支持 - GORM 写法示例：
var records []DeviceHistory db.Where("device_id = ?", deviceID). Where("(created_at, id) < (?, ?)", lastCreatedAt, lastID). Order("created_at DESC, id DESC"). Limit(50). Find(&records) - 必须给
(device_id, created_at, id)建联合索引，否则游标失效
时间范围 + 设备 ID 查询时的索引陷阱
很多项目只建了 INDEX(device_id) 或 INDEX(created_at) 单列索引，但设备历史查询几乎总是带这两个条件。MySQL 优化器在多条件查询中可能只选其一，导致慢查。
- 正确索引顺序应为：
INDEX(device_id, created_at, id)—— 先过滤设备，再按时间裁剪，最后用id定位游标位置 - 如果还要支持按
status过滤（如只查“在线”状态），可扩展为：INDEX(device_id, status, created_at, id)，但注意索引宽度增加会影响写入性能 - 避免在
created_at上用函数，比如WHERE DATE(created_at) = '2026-08-20'，这会让索引失效；改用范围：WHERE created_at >= '2026-08-20 00:00:00' AND created_at
大时间跨度查询的兜底方案
用户偶尔会查“过去 30 天所有设备数据”，这种场景游标分页意义不大，但直接 Limit/Offset 又容易超时。稳妥做法是加一层时间分区控制：
- 按天或按小时建表（如
device_history_20260820），GORM 可通过TableName()方法动态切换 - 或者用 MySQL 的
PARTITION BY RANGE (TO_DAYS(created_at))，让优化器自动裁剪分区 - 查询前先估算时间范围内数据量：
SELECT COUNT(*) FROM device_history WHERE created_at BETWEEN ? AND ?，若超过 10 万行，强制走游标分页并提示“建议缩小时间范围”
游标分页不是银弹——它要求排序字段绝对稳定、索引设计必须匹配查询模式、前端需妥善保存上一页末尾值。一旦设备端时间不同步导致 created_at 乱序，整个分页逻辑就不可靠。所以生产环境务必校准设备系统时间，并在写入前做基础合理性校验（比如拒绝早于 7 天前的时间戳）。
