gorm的limit/offset分页在物联网场景下极易拖垮数据库，因offset大时数据库需逐行扫描丢弃前n行，非跳过；应改用created_at+id复合游标分页，并显式配置连接池与预处理语句。
直接说结论：GORM 默认的 Limit/Offset 分页在物联网场景下极易拖垮数据库，尤其当设备上报频次高、单表超千万行时，OFFSET 1000000 这类查询会触发全表扫描，不是“慢”，而是“卡死”。必须换策略。
为什么 GORM 的 Offset 分页在 IoT 场景下失效
物联网数据有三个典型特征：写多读少、时间序列密集、分页常需“查最近 N 条”或“按时间范围翻页”。但 Offset 分页依赖行号跳转，MySQL/PostgreSQL 在大偏移量时无法利用索引跳过前 N 行，只能逐行计数。实测 MySQL 8.0 下 OFFSET 500000 查询耗时从 12ms 暴涨到 2.3s，且随着数据增长线性恶化。
更隐蔽的问题是：GORM 的 Count + Find 两步分页（如 db.Model(&DeviceLog{}).Count(&total).Offset(page*limit).Limit(limit).Find(&logs)）会让 Count 也走全表扫描——哪怕你只想要最后一页的 20 条记录。
- 设备日志表无业务主键，仅靠自增
id或时间戳created_at排序 - 前端请求常带模糊条件（如
device_id LIKE 'DEV-%'），进一步削弱索引效率 - GORM 默认不强制使用覆盖索引，
SELECT *加WHERE组合容易触发回表
用游标分页替代 Offset：GORM 中怎么写
游标分页（Cursor-based Pagination）用上一页最后一条记录的排序字段值作为下一页起点，避免偏移计算。对时间序列数据，天然适合用 created_at + id 复合游标。
关键不是“GORM 支持游标”，而是你得绕过 Offset，手写条件：
- 首次请求：不带游标，按时间倒序取最新 50 条：
db.Where("created_at - 后续请求：传上一页最后一条的
created_at和id，用严格小于条件：db.Where("created_at - 必须给
(created_at, id)建联合索引，否则性能无保障
注意：GORM 不会自动帮你拼这个 OR 条件，也不能用 Where().First() 替代，因为 First() 会加 LIMIT 1 并可能改变排序语义。
报表聚合查询中，GORM 的 Scan 和 Raw SQL 怎么选
物联网报表常要按小时/天统计设备在线数、平均上报延迟等，这类聚合本身不复杂，但 GORM 的 Group + Select 容易踩坑：
-
db.Table("device_logs").Select("DATE(created_at) as day, COUNT(*)").Group("day").Scan(&result)—— 看似简洁，但Scan要求结构体字段名与 AS 别名完全一致，且类型必须匹配（DATE()返回的是字符串，不是time.Time） - 一旦聚合字段含函数（如
HOUR(created_at)）、CASE WHEN 或跨表 JOIN，GORM 的链式构建极易生成语法错误或忽略别名 - 生产环境建议：用
db.Raw()写明确 SQL，再用Scan()映射到结构体。例如：db.Raw("SELECT DATE(created_at) as day, COUNT(DISTINCT device_id) as online_count FROM device_logs WHERE created_at >= ? GROUP BY day", startTime).Scan(&dailyStats)
别迷信“全 ORM”，GORM 的价值在 CRUD 和关联管理，不在复杂报表——后者交给 SQL 更可控，也更容易加 EXPLAIN 分析执行计划。
连接池和预处理语句必须显式配置
海量设备并发写入时，GORM 默认连接池（MaxOpenConns=0 即不限制，MaxIdleConns=2）会导致连接数爆炸或空闲连接被误杀。而 IoT 场景下重复的插入/查询模板极多，不用预处理等于放弃性能底线。
- 初始化时必须设置：
db.Config.ConnPool = &sql.DB{...}; db.Config.ConnPool.SetMaxOpenConns(50); db.Config.ConnPool.SetMaxIdleConns(20) - 对高频插入（如每秒万级日志），用
db.Session(&gorm.Session{PrepareStmt: true})开启预处理，让 MySQL 复用执行计划 - 注意：SQLite 驱动不支持预处理，若用 SQLite 做边缘节点缓存，得单独处理
最易被忽略的一点：GORM V2 的 PrepareStmt 是按 session 生效的，不是全局开关。写报表接口时如果忘了加，那条 Raw 查询就只是普通文本拼接，毫无性能优势。
