这种分页后索引突然失效的问题在Oracle 10g里真的很常见，尤其是手动编写分页逻辑的时候。我帮你拆解下可能的原因，再给几个实操性强的解决办法：

问题根源分析 #

• Rownum的局限性：第一页查询（WHERE rownum <=30）时，Oracle优化器可以直接借助索引快速抓取前N条数据——因为rownum是在结果集生成过程中逐行标记的，走索引的成本极低。但当查询后续页面时，手动分页通常会写成两层嵌套子查询：内层先取前60条，外层再过滤掉前30条。这时候优化器可能会认为，先全表扫描取60条再过滤的成本比走索引更低，尤其是当表的统计信息不准确时，就会直接放弃索引。
• 多索引的干扰：你的表带有多个索引，优化器需要评估选择哪个索引（或者组合索引）更高效。当分页逻辑变成两层子查询后，优化器可能无法正确判断索引的价值，转而选择看似更“稳妥”的全表扫描。

可行的解决办法 #

1. 强制指定索引（应急方案） #

如果你明确知道某个索引是最优选择，可以用Oracle的提示（hint）强制优化器走该索引。示例代码如下：

SELECT *
FROM (
    SELECT /*+ INDEX(t your_target_index) */ t.*, rownum rn
    FROM your_recovery_table t
    WHERE your_query_conditions
    ORDER BY your_sort_column
)
WHERE rn > 30 AND rn <= 60;

⚠️ 注意：强制索引只在确定索引能提升性能时使用，否则可能会导致更差的执行计划。

2. 改用ROW_NUMBER()分析函数重构分页逻辑 #

Oracle 10g支持分析函数，用ROW_NUMBER()来实现分页，往往能让优化器更好地识别索引路径。写法如下：

SELECT *
FROM (
    SELECT t.*, ROW_NUMBER() OVER (ORDER BY your_sort_column) rn
    FROM your_recovery_table t
    WHERE your_query_conditions
)
WHERE rn > 30 AND rn <= 60;

这种方式的优势在于，优化器可以先通过索引完成条件过滤和排序，再给行号，相比两层rownum嵌套，更大概率会保留索引的使用。

3. 更新表的统计信息 #

如果表的统计信息过时，优化器会做出错误的成本估算，进而选错执行计划。你可以执行以下命令更新统计信息：

-- 方法1：ANALYZE命令
ANALYZE TABLE your_recovery_table COMPUTE STATISTICS;

-- 方法2：DBMS_STATS包（Oracle官方推荐）
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => 'your_schema_name', TABNAME => 'your_recovery_table', CASCADE => TRUE);

准确的统计信息能帮助优化器正确判断走索引和全表扫描的成本差异。

4. 优化索引结构（长期方案） #

如果你的分页查询需要排序，确保排序字段包含在索引中（最好是索引的前缀）。比如你的查询按create_time排序，同时过滤status字段，那么可以创建包含status, create_time的组合索引。这样优化器可以直接通过索引完成过滤和排序操作，避免额外的排序步骤，分页时也更愿意选择索引路径。

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