gorm官方不支持非关系型数据库，其limit/offset分页在数据库代理环境下必然失效，因代理会破坏sql可预测性、跨分片offset无法对齐、order by失效、count不准；正确做法是改用db.raw()手写适配sql或下沉分页至代理层。
GORM 是专为关系型数据库设计的 ORM，不支持非关系型数据库代理场景下的分页适配——这不是配置问题，而是架构层面的不可行。
你看到的“GORM + 非关系型数据库”组合，基本都落在以下三类情况中：
- 用 GORM 连 PostgreSQL/MySQL，但前端请求经由某中间件（如 ProxySQL、ShardingSphere）路由；
- 误将 MongoDB/Redis/Elasticsearch 等当作 GORM 的合法 driver 使用（GORM 官方 driver 列表里没有它们）；
- 第三方魔改版或封装层（如某些内部 SDK）对外暴露了类似 GORM 的 API，但底层完全绕开了 GORM 的
Session、Statement和Clause机制。
为什么 GORM 的 Limit/Offset 在代理后可能失效
代理层（尤其是读写分离、分库分表类）会修改 SQL 行为，而 GORM 的分页严重依赖原始 SQL 可预测性：
-
OFFSET值在跨分片查询时无法全局对齐：比如OFFSET 1000在 A 片查出 10 条，在 B 片也查出 10 条，合并后实际跳过的不是 1000 条，而是各片独立跳过 —— 结果错乱 - 代理可能重写
ORDER BY或忽略它（尤其当排序字段未出现在分片键中），导致 GORM 要求的「确定性顺序」彻底崩溃 -
COUNT(*)查询被代理拆成多个子查询再 SUM，但 GORM 的Count()不感知该语义，返回值常为单片结果，总数严重不准 - 某些代理（如 Vitess）会把
LIMIT 20 OFFSET 1000改写为LIMIT 1020再内存截断，但 GORM 没法控制这个行为，也无法校验改写是否安全
哪些“分页”调用在代理环境下必然出错
以下写法在经过典型数据库代理（如 ProxySQL、MyCat、ShardingSphere-JDBC）时，大概率返回错误数据或 panic：
-
db.Offset(1000).Limit(20).Order("id ASC").Find(&users)：代理无法保证跨节点 id 全局有序，id ASC失效 -
db.Where("status = ?", "active").Count(&total)：若代理未开启全局 COUNT 聚合，total是单个物理库的结果 -
db.Scopes(PaginateScope).Find(&users)：自定义Scope仍生成标准 LIMIT/OFFSET，代理无从识别业务意图 -
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Count(&total)：仅隔离 GORM 链式调用，不穿透代理层逻辑
真要走代理，分页必须放弃 GORM 原生链式写法
可行路径只有一条：绕过 GORM 的查询构造器，直接控制最终 SQL 和参数传递方式：
- 用
db.Raw()手写适配代理规则的分页 SQL，例如对 ShardingSphere 使用SELECT * FROM users /*+ sharding hint */ WHERE ... LIMIT ? OFFSET ? - 把分页逻辑下沉到代理配置层：比如在 ProxySQL 中用
mysql_query_rules对含LIMIT的请求打标，再由后端按标路由 - 禁用 GORM 的
Find()/Count()，全部改用db.Raw().Scan()+ 显式sql.Rows解析，确保每条语句可控 - 游标分页字段（如
last_id）必须选代理能下推的列：主键或分片键，避免用created_at这类易跨片重复且无索引下推能力的字段
关键点在于：代理不是透明管道，它是有状态的查询重写器。GORM 的抽象模型与之天然冲突，强行复用只会掩盖问题，不会解决问题。
