必须用paginationinnerinterceptor且不指定dbtype，否则多数据源下会全局错用方言；显式传dbtype.oracle会导致所有数据源强制走oracle分页逻辑，忽略实际数据库类型，使postgresql等查询生成rownum语句而报错。
必须用 PaginationInnerInterceptor，且不能指定 DbType.ORACLE —— 否则多数据源下会全局错用方言；正确做法是不传 DbType，让框架自动识别。
为什么显式传 DbType.ORACLE 反而会出问题
很多人照着老文档写 new PaginationInnerInterceptor(DbType.ORACLE)，结果在 Oracle + PostgreSQL 混合数据源项目里，PostgreSQL 查询也生成了 ROWNUM 语句，直接报错。这是因为 PaginationInnerInterceptor 构造时硬编码了 dbType，导致它忽略实际连接的数据库类型，强制走 Oracle 方言。
源码里 findIDialect() 方法逻辑很明确：如果实例上已有 dbType，就直接用它；否则才查 JDBC URL 自动推断。所以显式传参等于锁死了方言，跨库场景下必然失效。
- 错误配置：
interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.ORACLE)) - 正确配置：
interceptor.addInnerInterceptor(new PaginationInnerInterceptor()) - 验证方式：查日志，Oracle 查询应出现
WHERE ROWNUM ?，PostgreSQL 应为LIMIT ? OFFSET ?
Page 构造必须带 pageNum 和 pageSize
new Page() 看似简洁，但默认 current = 1、size = 10 在部分环境（比如 YashanDB 或某些 Oracle 驱动版本）下会被忽略，导致查出全表数据。这不是 Bug，而是某些 JDBC 层对空参数的处理差异。
- 安全写法：
Page<user> page = new Page(pageNum, pageSize)</user>，其中pageNum从 1 开始 - 前端传
pageNum=0或负数时，PaginationInnerInterceptor会静默归零或抛异常，建议在 Controller 层提前校验 - 避免用
Page<user> page = new Page().setCurrent(1).setSize(10)</user>，链式调用不保证构造完成前参数已生效
别和 PageHelper 共存
如果项目里同时存在 PageHelper（比如用了 pagehelper-spring-boot-starter），两个拦截器会先后重写 SQL —— 第一次加 LIMIT，第二次再套一层 ROWNUM，最终语句既不符合 Oracle 也不符合 MySQL 语法，大概率报 ORA-00936 或空结果。
- 检查依赖树：
mvn dependency:tree | grep pagehelper，确认是否意外引入 - Maven 排除示例：
<exclusions><exclusion><groupid>com.github.pagehelper</groupid><artifactid>pagehelper</artifactid></exclusion></exclusions> - YashanDB 虽兼容 Oracle 的
ROWNUM，但它不认pagehelper.helperDialect=oracle这套配置，混用必冲突
调试分页是否真正生效的关键点
只看返回数据量是否“看起来像分页”是靠不住的。有些场景下 selectPage() 返回的 IPage 对象里 getTotal() 是 0 或 -1，getRecords().size() 却等于全表条数 —— 这说明拦截器根本没介入 SQL 改写。
- 必须开启 MyBatis DEBUG 日志：
logging.level.com.baomidou.mybatisplus=DEBUG - 重点盯日志里的
Preparing: SELECT行，确认是否含分页关键词（ROWNUM/LIMIT/OFFSET） - 如果看到原始 SQL 没被改写，先检查
MybatisPlusInterceptorBean 是否被 Spring 正确加载（加个@PostConstruct打印日志） - 多数据源时，确保每个
SqlSessionFactory都绑定了同一个MybatisPlusInterceptor实例，而不是各自 new 一个
