Oracle 11g 不支持 FETCH FIRST，19c 弱化 ROWNUM 嵌套兼容性，语法无交集且无法自动降级；必须由应用层识别版本并动态切换分页写法，拦截器方案可精准控制重写时机与逻辑。
直接用 oracle 11g 的 rownum 分页在 19c 上会出错，但硬切到 fetch first 又会让 11g 报 ora-00933；拦截器动态改 sql 是目前最稳妥的运行时兼容方案。
为什么不能统一用一种分页语法
Oracle 11g 不支持 FETCH FIRST 和 OFFSET，执行会报 ORA-00933: SQL command not properly ended；而 19c 默认禁用旧式 ROWNUM 嵌套写法（尤其带 ORDER BY 时），容易返回非预期结果或性能陡降。两者语法层不交集，且数据库无法自动降级/升級解析——必须由应用层识别版本并切换。
如何在 EF Core 中用拦截器识别 Oracle 版本并改写 SQL
EF Core 6+ 支持 DbCommandInterceptor，可在命令执行前检查连接的数据库版本，并对含 LIMIT、OFFSET 或分页标记的 SQL 做重写。关键点：
- 通过
connection.ServerVersion获取真实版本号（不是连接字符串里写的，是实际握手后返回的） - 不要依赖
Oracle.ManagedDataAccess的OracleConnection.ServerVersion字符串解析——它可能截断为"19.0"或"11.2"，需用正则提取主版本：Regex.Match(version, @"^(\d+)\.")?.Groups[1].Value - 只拦截明确带分页意图的命令：比如 SQL 中包含
__p_0、@p0且语句含ORDER BY和占位符模式（如/* pagination */注释） - 11g 路径重写为双层
ROWNUM：SELECT * FROM (SELECT a.*, ROWNUM rnum FROM (/* original */) a WHERE ROWNUM @start - 19c 路径保留或转为
OFFSET @start ROWS FETCH NEXT @size ROWS ONLY（注意：19c 要求ORDER BY必须存在，否则报错）
拦截器里容易踩的坑
常见错误不是逻辑错，而是时机和副作用失控：
- 在
CommandExecuting阶段修改command.CommandText后，没同步更新command.Parameters顺序——导致参数错位，查出脏数据 - 对非查询命令（如
INSERT、UPDATE）也做了分页重写，引发语法错误 - 用字符串
.Contains("ORDER BY")判断，但注释里有ORDER BY或字段名含该子串，误触发重写 - 没处理
UNION ALL子查询场景：11g 要求外层再套一层ROWNUM，否则ORDER BY无效；19c 的FETCH必须在最外层 - 忽略大小写：Oracle 默认不区分，但某些驱动（如 ODP.NET Core）传入的 SQL 是大写，匹配时要用
IndexOf(..., StringComparison.OrdinalIgnoreCase)
比拦截器更轻量的替代方案：Dapper + 自定义分页扩展
如果项目没强绑 EF Core，Dapper 更易控制 SQL 生成路径：
- 封装一个
QueryPaged<T>(sql, param, page, size, dbVersion)方法，由调用方显式传入版本 - 避免在 ADO.NET 层做字符串替换，直接拼接不同模板：
BuildRownumSql()/BuildFetchSql() - 把版本探测下沉到连接初始化阶段，缓存到
DbContext或DbConnection的ExtendedProperties里，避免每次查V$VERSION - 测试时务必覆盖边界：空结果集、
page=1, size=0、size > 10000（19c 对OFFSET有隐式性能警告）
真正麻烦的从来不是语法切换，而是同一条业务 SQL 在两个版本上因优化器路径不同导致分页偏移错位——比如 11g 索引快速全扫描 + ROWNUM 截断，19c 改走排序合并连接再 FETCH，结果顺序不一致。这种必须靠 ORDER BY 字段加唯一性约束兜底，光改分页没用。
