Oracle 12c+ 支持 OFFSET/FETCH，但大偏移量性能差；需校验整数后拼接OFFSET/FETCH参数，ROWNUM分页须显式声明Int32类型并启用BindByName；排序字段必须有匹配前导顺序的索引。
Oracle 12c+ 用 OFFSET/FETCH 最简但有陷阱
Oracle 12c 起原生支持 OFFSET/FETCH，写法直观，但性能未必最优——尤其当 OFFSET 值很大时（比如第1000页），数据库仍需扫描前 N 行再丢弃，CPU 和 I/O 开销陡增。
实操建议：
- 仅对小偏移量（
OFFSETSELECT * FROM orders ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY - 避免在无索引排序字段上使用，否则
ORDER BY本身就会触发全表排序 - 必须确保
ORDER BY字段有高效索引，且该索引覆盖查询所需列（或搭配INCLUDE列），否则回表成本高
Oracle 11g 及更早版本只能靠 ROWNUM 嵌套，但写错就全错
经典三层嵌套写法是唯一可靠方式，但第二层的 ROWNUM 必须紧贴 <code>ORDER BY 结果，否则因执行顺序导致分页错乱——这是最常踩的坑。
正确结构（以 C# 参数化为例）：
SELECT * FROM (
SELECT a.*, ROWNUM rnum FROM (
SELECT * FROM orders ORDER BY id
) a WHERE ROWNUM :startRow
注意点：
-
:startRow和:endRow必须是int类型参数，不能传字符串或 null；C# 中用new OracleParameter("startRow", start)显式指定类型 - 外层
WHERE rnum > :startRow不能写成WHERE ROWNUM > :startRow——ROWNUM在结果集生成时即赋值，无法在 WHERE 中过滤大于某值 - 若查询含
LOB字段（如CLOB），嵌套后可能触发隐式转换或性能抖动，建议显式SELECT非 LOB 列，LOB 单独按主键查
C# 中用 OracleCommand 绑定分页参数要防 SQL 注入和类型失配
拼接字符串生成分页 SQL 是高危操作，必须全程参数化。但 Oracle 的参数绑定对数字类型敏感，尤其 OFFSET/FETCH 子句不接受参数占位符（Oracle 报错 ORA-00933: SQL command not properly ended）。
安全做法：
- 对
OFFSET/FETCH场景：用string.Format或插值字符串拼接整数参数（确保已校验为正整数），再用其余参数（如 WHERE 条件）走OracleParameter - 对
ROWNUM嵌套：所有行号参数（:startRow,:endRow）必须用OracleDbType.Int32显式声明，否则驱动可能推断为字符串导致隐式转换失败 - 设置
command.BindByName = true，避免因参数顺序错乱引发错位绑定
真正影响性能的不是语法，是排序字段是否走索引
无论用哪种分页语法，如果 ORDER BY 字段没索引，或者索引选择性差（如 status 只有 3 个值），分页查询会退化为全表扫描 + 大内存排序，响应时间随页码线性增长。
验证与优化步骤：
- 在 SQL Developer 中对分页语句执行
EXPLAIN PLAN，重点看Operation是否含INDEX RANGE SCAN或INDEX FULL SCAN，而非TABLE ACCESS FULL - 若排序字段是复合条件（如
ORDER BY tenant_id, created_time），索引必须是(tenant_id, created_time)前导顺序，不可颠倒 - 避免在
ORDER BY中使用函数（如ORDER BY UPPER(name)），除非建了函数索引且 C# 查询中显式调用相同函数
分页本身只是表象，底层数据分布和索引设计才是决定快慢的关键。写完语句别急着测接口，先看执行计划里那几行关键操作。
