mysql 5.7仅支持limit offset, row_count，8.0起支持标准offset ... fetch，兼容方案是统一用limit写法并预计算offset值，禁用offset fetch以避免5.7报错。
MySQL 5.7 和 8.0 的分页语法差异怎么处理？
MySQL 5.7 只支持 LIMIT offset, row_count，而 8.0 开始支持标准 SQL 的 OFFSET ... FETCH。但直接混用会出错：在 5.7 执行 OFFSET 10 ROWS FETCH NEXT 20 ROWS ONLY 会报 ERROR 1064。
- 如果必须兼容两个版本，放弃
OFFSET ... FETCH，统一用LIMIT写法 -
OFFSET值需提前计算好（比如第 3 页、每页 20 条 →OFFSET 40），不能依赖数据库解析动态表达式 - 注意：MySQL 5.7 不支持子查询带
LIMIT在IN/JOIN中直接使用，若做“查主键再关联”分页，得用临时表或应用层拆解
PostgreSQL 和 SQL Server 的 OFFSET FETCH 能否直接复用？
PostgreSQL 8.4+ 和 SQL Server 2012+ 都支持 OFFSET ... FETCH，但细节不同：
- PostgreSQL 允许
OFFSET 0 ROWS FETCH FIRST 10 ROWS ONLY，也允许省略ROWS（FETCH FIRST 10 ROWS ONLY） - SQL Server 要求显式写
OFFSET ... ROWS FETCH NEXT ... ROWS ONLY，缺一不可，否则报Incorrect syntax near 'FETCH' - 两者都不支持
FETCH后跟变量（如@size），必须传字面量或参数化查询绑定值
所以“通用”不等于“写一次全跑通”，而是统一用参数化方式生成语句：对 PostgreSQL 和 SQL Server 构造 OFFSET ? ROWS FETCH NEXT ? ROWS ONLY；对 MySQL 则 fallback 到 LIMIT ?, ?。
Oracle 12c+ 的 ROWNUM 和 OFFSET FETCH 如何选？
Oracle 12c 引入了 OFFSET ... FETCH，但老代码常用 ROWNUM 嵌套写法，两者性能和语义有差别：
-
ROWNUM方式（如SELECT <em> FROM (SELECT a.</em>, ROWNUM rnum FROM (...) a WHERE ROWNUM 10）在无索引时可能全表扫描后再过滤，效率低 -
OFFSET ... FETCH是原生支持，优化器能更好规划执行计划，但要求 Oracle ≥ 12.1.0.2 - 如果要兼容 11g，只能用
ROWNUM套娃，且必须确保外层WHERE条件写在最内层子查询里，否则ROWNUM分配顺序出错
实际项目中，建议检测 SELECT * FROM v$version 结果，≥12c 就走 OFFSET FETCH，否则降级用 ROWNUM 模式——别试图用同一套 SQL 适配所有 Oracle 版本。
跨数据库分页的参数安全与性能陷阱
分页参数（page、size）若未经校验直接拼进 SQL，轻则越界查空，重则触发全表扫描或内存溢出：
-
size必须限制上限（如 ≤ 100），否则LIMIT 1000000在大表上可能卡死连接 -
offset过大会导致 MySQL/PostgreSQL 性能陡降（跳过前 N 行仍需遍历），此时应改用游标分页（WHERE id > ? ORDER BY id LIMIT ?） - JDBC 中用
PreparedStatement绑定参数，绝不用字符串拼接OFFSET或LIMIT，否则 Oracle 会报ORA-00933: SQL command not properly ended，SQL Server 可能触发注入
真正麻烦的不是语法差异，而是不同数据库对“跳过大量行”的物理实现完全不同——MySQL 用偏移计数，PostgreSQL 用元组跳转，Oracle 用 ROWID 定位。没做数据量预估就写 OFFSET 100000，在任意数据库上都容易翻车。
