历史备份表分页必须手动控制offset和limit，因gorm无原生paginate方法、表常无主键或主键不连续、count易受前置limit污染、order缺失导致乱序、动态表名需隔离会话、超大表宜用近似统计或游标分页。
为什么历史备份表分页必须手动控制 Offset 和 Limit
GORM 没有原生 Paginate 方法，历史备份表通常字段少、无主键或主键不连续（比如用 backup_id + batch_no 复合标识），Preload 和 Joins 基本用不上，但 Offset/Limit 仍可能出错。关键不是“能不能用”，而是“怎么用才不翻车”：备份表往往数据量大、写入后极少更新，但首次分页若没加 Order，MySQL 可能返回乱序结果；而 Count(&total) 若复用同一 *gorm.DB 实例，会把 Limit 也带进统计 SQL，导致 total 永远 ≤ pageSize。
-
Offset((page - 1) * pageSize)前必须确保page ≥ 1且pageSize > 0，否则Offset传负数直接 panic - 备份表常缺索引，
Order("id ASC")若id无索引，排序本身就会变慢查询 - 如果表名是动态的（如
backup_202607），不能靠db.Table("backup_202607")后直接链式调用Count——它仍会污染后续查询的WHERE条件 - 推荐显式用
db.Session(&gorm.Session{NewDB: true})隔离总数查询，避免条件残留
如何安全查总数：别信链式调用的 Count
对历史备份表，db.Where("status = ?", "done").Model(&BackupLog{}).Count(&total) 看似合理，但若前面某次查询用了 Limit(100) 且没重置 DB 实例，这个 Count 就会悄悄带上 LIMIT 100，返回错误的 total。更糟的是，有些备份表用时间分区（如 backup_202601 ~ backup_202607），你得先确认当前查的是哪张物理表。
- 总数查询务必新建会话：
db.Session(&gorm.Session{NewDB: true}).Model(&BackupLog{}).Where(...).Count(&total) - 如果表名是变量，用
db.Table(tableName).Where(...).Count(&total)，但注意Table()不影响Model()的结构体映射，Count仍需指定模型或用Raw - 超大备份表（>500 万行）慎用
COUNT(*)，可改用近似值：db.Raw("SELECT table_rows FROM information_schema.tables WHERE table_name = ? AND table_schema = DATABASE()", tableName).Scan(&approx)（仅 MySQL） - 业务允许时，前端只传
cursor（上一页最后一条的created_at和id），后端查WHERE created_at >= ? AND id > ? ORDER BY created_at, id LIMIT ?，彻底绕过Count
备份表分页的 Order 字段选哪个才稳
历史备份表常见字段：id（自增但可能被删）、backup_time（精度到秒，易重复）、file_hash（无序）。随便选一个 Order 字段，翻页时大概率漏数据或重复。例如只写 Order("backup_time DESC")，两行记录 backup_time 相同，数据库返回顺序不确定，第 2 页可能把第 1 页末尾那条又捞出来。
- 优先用
Order("backup_time DESC, id DESC")：时间戳为主，id为辅，保证组合唯一且有序 - 若
id是 UUID 或无序字符串，改用Order("backup_time DESC, created_at DESC")（假设created_at是插入时间） - 必须给
ORDER BY字段建联合索引，例如INDEX idx_time_id (backup_time, id)，否则排序走 filesort，分页越往后越慢 - 绝对不要用
Order("RAND()")或Order("file_size")——前者无法翻页，后者字段无索引，查第 100 页时可能扫全表
游标分页在备份场景下其实更简单
历史备份表写入后基本不动，按时间归档，天然适合游标分页。你不需要维护 page 参数，前端只需传上一页最后一条的 backup_time 和 id，后端拼 WHERE backup_time 。没有 <code>OFFSET，性能不随页码增长而下降，总数也不用查。
- 首次请求不带游标，SQL 改成
WHERE backup_time - 返回数据时，取
users[len(users)-1].BackupTime和.ID作为下一页cursor，base64 编码防篡改 - 注意 NULL 处理：如果
backup_time允许为空，WHERE backup_time 会漏掉空值行，需额外 <code>OR backup_time IS NULL并调整排序逻辑 - GORM v2 不支持原生游标分页，但手写
Where+Order+Limit三行代码就搞定，比折腾第三方插件更可靠
真正容易被忽略的点是：备份表的 Count 查询和主查询必须完全隔离，哪怕只是多了一个 Where 条件没清掉，total 就会错；还有就是 Order 字段没索引时，分页性能断崖下跌的位置不是第 100 页，而是第 3 页——因为排序本身已成瓶颈。
