MySQL和PostgreSQL均用LIMIT控制行数，但语法不同：MySQL支持LIMIT offset, count（如LIMIT 5, 10），PostgreSQL仅支持LIMIT count OFFSET offset（如LIMIT 10 OFFSET 5），且必须置于ORDER BY之后以保证结果确定性。
MySQL 和 PostgreSQL 用 LIMIT 控制行数
MySQL 和 PostgreSQL 都直接支持 LIMIT，语法简单，但位置和参数含义容易混淆。它必须放在语句末尾，不能嵌在 WHERE 或 ORDER BY 中间。
-
LIMIT 10：取前 10 行 -
LIMIT 5, 10（MySQL）或LIMIT 10 OFFSET 5（PostgreSQL）：跳过前 5 行，再取 10 行 - 如果配合
ORDER BY使用，LIMIT一定在它之后，否则会报错：ERROR: syntax error at or near "LIMIT" - 注意：MySQL 的
LIMIT offset, count写法在 PostgreSQL 中不兼容，迁移时要改写为OFFSET ... LIMIT ...
SQL Server 和 Oracle 用 TOP / FETCH FIRST
SQL Server 用 TOP，Oracle 12c+ 用 FETCH FIRST，两者都不支持偏移量的单关键字写法，必须显式组合 ORDER BY 才能分页。
- SQL Server：
SELECT TOP 10 * FROM users；带跳过需用OFFSET ... ROWS FETCH NEXT ... ROWS ONLY - Oracle：
SELECT * FROM users ORDER BY id FETCH FIRST 10 ROWS ONLY；跳过前 5 行得写成OFFSET 5 ROWS FETCH NEXT 10 ROWS ONLY - 没有
ORDER BY时，SQL Server 允许TOP，但 Oracle 会报错：ORA-00933: SQL command not properly ended - SQL Server 的
TOP可加PERCENT，比如TOP 10 PERCENT；Oracle 不支持百分比限制
SQLite 的 LIMIT 支持最宽松，但分页性能差
SQLite 完全兼容 MySQL 风格的 LIMIT offset, count，写法最省事，但底层是逐行扫描跳过 offset 行，数据量大时明显变慢。
- 例如
SELECT * FROM logs LIMIT 100000, 10会先读 100010 行再丢弃前 100000 行 - 替代方案是用游标分页：记录上一页最后的
id，下一页查WHERE id > ? LIMIT 10 - SQLite 不支持
FETCH FIRST，用高版本 Oracle 或 PostgreSQL 语法会直接报错：near "FETCH": syntax error
跨数据库分页的兼容写法很难，别硬套一个语法
没有一种 LIMIT 写法能在所有主流数据库中通用。ORM（如 SQLAlchemy、Django ORM）内部做了方言适配，但裸 SQL 必须按目标数据库选型。
- 如果用 JDBC/ODBC 连接多库，建议把分页逻辑提到应用层：先查总数，再根据数据库类型拼不同 SQL
- 误用
LIMIT在 SQL Server 上会触发：Incorrect syntax near 'LIMIT' - Oracle 11g 及更早版本连
FETCH FIRST都不支持，只能靠ROWNUM嵌套子查询，写法更绕且易出错
真正麻烦的不是语法本身，而是 offset 越大，数据库越可能放弃索引走全表扫描——这点在写分页接口时最容易被忽略。
