Oracle 12c起支持OFFSET/FETCH分页语法，但GORM默认生成的LIMIT/OFFSET在Oracle中会报ORA-00933错误；需依赖godror驱动转换或改用ROWNUM嵌套子查询、ROW_NUMBER()窗口函数，推荐优先使用OFFSET/FETCH（12c+）或游标分页以保障性能与稳定性。
Oracle 的 OFFSET/LIMIT 语法不原生支持
Oracle 直到 12c 才通过 OFFSET ... ROWS FETCH NEXT ... ROWS ONLY 支持标准分页语法，但 GORM v2 默认生成的 SQL 仍按 MySQL/PostgreSQL 风格拼 LIMIT 和 OFFSET —— 这在 Oracle 上会直接报错 ORA-00933: SQL command not properly ended。
根本原因：GORM 的 Limit() 和 Offset() 是数据库无关抽象，底层依赖驱动对 SQL 的重写能力。godror 驱动虽支持自动转换，但仅限简单查询；一旦含 ORDER BY 子句缺失、或使用了 UNION/JOIN，转换极易失败或返回错误结果。
- 必须显式调用
Order("id ASC")（或带索引的确定性字段），否则 godror 无法安全注入FETCH子句 - 避免在分页链中混用
Joins或Group：godror 对复杂子查询的OFFSET/FETCH重写不可靠，建议手写原生 SQL - 测试时务必验证第一页和最后一页：Oracle 对
OFFSET 0和大偏移量（如OFFSET 100000）的执行计划差异极大，可能触发全表扫描
游标分页在 Oracle 上更稳，但要注意 ROWNUM 陷阱
Oracle 传统分页常用 ROWNUM 嵌套子查询（如 SELECT * FROM (SELECT ROWNUM r, t.* FROM (...) t) WHERE r BETWEEN ? AND ?），但这种写法与 GORM 的链式调用天然冲突——ROWNUM 必须在最内层生效，而 GORM 的 Where/Order 会破坏嵌套结构。
更可靠的做法是放弃 ROWNUM，改用 12c+ 的 OFFSET/FETCH 游标模式，但需手动控制条件：
- 首请求：
db.Order("id ASC").Limit(20).Find(&users) - 后续请求：
db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users)（注意：此处不加OFFSET，完全由WHERE驱动） - 别依赖
created_at单字段游标：Oracle 默认时区和DATE精度（秒级）易导致漏数据，必须搭配id复合排序，例如Order("created_at DESC, id DESC")+Where("created_at
Count 查询在 Oracle 上容易慢且不准
GORM 的 Count() 在 Oracle 中默认走 SELECT COUNT(*) FROM ...，但若主查询含 JOIN 或 WHERE 条件，直接复用链式 DB 实例会导致条件丢失或重复计数——尤其当关联表有 1:N 关系时，Count() 可能返回笛卡尔积数量而非主表记录数。
正确做法是隔离会话并手写子查询：
- 简单场景：
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total) - 带 JOIN 的场景：必须用
db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE p.active = ?) t", true).Scan(&total)，否则总数虚高 - 别信
db.Model(&User{}).Count()返回的值：它不感知任何前置Joins或Preload，纯按单表扫，毫无业务意义
Oracle 分页性能断崖点比 MySQL 更早
Oracle 的 OFFSET 性能劣化比 MySQL 更敏感：即使有主键索引，OFFSET 50000 也可能触发大量逻辑读，因为 Oracle 需先构造完整结果集再截取。实测中，当 OFFSET > 10000 时响应常超 800ms，且 PGA 内存占用陡增。
这意味着：哪怕总数据量仅 50 万行，也应强制前端切换游标分页，而不是容忍“用户只翻前 100 页”。
- 建复合索引时，把游标字段放最左：如
CREATE INDEX idx_users_cursor ON users (status, created_at DESC, id DESC)，确保WHERE status = ? AND created_at 能走索引范围扫描 - 避免在分页查询中用
SELECT *：Oracle 对大字段（CLOB/BLOB）的FETCH开销极高，只查必要字段 - 如果业务允许，用
has_next替代总数：查pageSize + 1条，有第pageSize + 1条就设has_next = true，彻底避开COUNT查询
游标分页不是“可选优化”，在 Oracle 上它是防止分页接口雪崩的底线措施；而任何依赖 OFFSET 的分页逻辑，只要没压测过 OFFSET 10000 场景，都算没上线。
