看起来你碰到了Kaminari在8000万条记录的Oracle表上分页性能极差的问题，我来帮你拆解一下原因和可行的解决方案：

问题根源分析 #

Kaminari针对Oracle数据库默认生成的三层嵌套ROWNUM分页SQL，虽然逻辑上能实现分页，但在超大数据量场景下，这种写法容易让Oracle优化器无法高效利用tickets.id的主键索引——哪怕id是主键且有索引，三层嵌套的结构可能迫使优化器先执行全表排序再筛选行，而非直接通过索引快速定位到前N条数据，这就是你看到近90秒耗时的核心原因。

具体解决方案 #

1. 启用Oracle 12c+原生分页语法（优先推荐） #

如果你的Oracle版本是12c或更高，Kaminari支持配置使用更高效的OFFSET ... FETCH NEXT语法，替代旧的ROWNUM嵌套逻辑。只需修改初始化配置：

# config/initializers/kaminari.rb
Kaminari.configure do |config|
  config.default_per_page = 10
  # 其他配置保持默认即可，重点添加下面这行
  config.oracle8i_compatible = false
end

修改后，Kaminari生成的SQL会变成：

SELECT "TICKETS".* FROM "TICKETS" ORDER BY TICKETS.ID DESC OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY

这种写法能让Oracle直接利用主键索引快速获取排序后的前10条数据，性能会有质的提升。

2. 强制优化器使用主键索引 #

如果暂时无法升级Oracle版本，或者修改配置后性能仍不理想，可以在查询中添加索引提示，强制优化器走主键索引：

# 替换PK_tickets为你的tickets表主键索引实际名称
Ticket.order("tickets.id desc").page(1).without_count.per(10).hint('/*+ INDEX(tickets PK_tickets) */')

你可以通过以下SQL查询到准确的主键索引名：

SELECT index_name FROM user_indexes WHERE table_name = 'TICKETS' AND uniqueness = 'UNIQUE';

3. 更新表统计信息 #

Oracle优化器依赖准确的表统计信息生成最优执行计划，8000万条记录的表很可能存在统计信息过时的情况。执行以下命令更新统计信息：

-- 方式1
ANALYZE TABLE TICKETS COMPUTE STATISTICS;

-- 方式2（推荐用DBMS_STATS包）
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => '你的数据库用户名', TABNAME => 'TICKETS', CASCADE => TRUE);

4. 自定义分页逻辑（终极方案） #

如果以上方法都不生效，你可以绕过Kaminari的默认分页，直接用原生SQL构造更高效的查询：

Ticket.find_by_sql([
  "SELECT * FROM TICKETS ORDER BY ID DESC OFFSET :offset ROWS FETCH NEXT :limit ROWS ONLY",
  offset: 0, limit: 10
])

这种写法完全由你控制SQL结构，能确保Oracle使用最优的执行计划。

验证优化效果 #

修改后，你可以通过EXPLAIN PLAN查看执行计划，确认是否用到了主键索引：

-- 针对新分页语法的执行计划
EXPLAIN PLAN FOR
SELECT "TICKETS".* FROM "TICKETS" ORDER BY TICKETS.ID DESC OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY;

如果执行计划中出现INDEX FULL SCAN DESCENDING（主键索引的降序全扫描），说明已经在高效利用索引了。

内容的提问来源于stack exchange，提问作者Lavanya Ramamoorthy