mysql支持limit offset, count写法，postgresql仅支持limit count offset offset；二者均需配合order by保证结果确定性，且offset越大性能越差，推荐游标分页替代。
MySQL 和 PostgreSQL 中 LIMIT 语法差异
MySQL 和 PostgreSQL 都支持 LIMIT，但 PostgreSQL 还必须搭配 OFFSET 才能实现跳过前 N 行，而 MySQL 允许 LIMIT offset, count 的双参数写法。不注意这点，直接把 MySQL SQL 搬到 PostgreSQL 会报错 syntax error at or near "OFFSET" 或提示缺少 OFFSET。
- MySQL 写法：
SELECT * FROM users LIMIT 10, 20（跳过前 10 行，取 20 行） - PostgreSQL 写法：
SELECT * FROM users LIMIT 20 OFFSET 10 - SQLite 支持两种写法，但推荐用
LIMIT 20 OFFSET 10，兼容性更好
LIMIT 不加 ORDER BY 可能返回不稳定结果
LIMIT 本身不保证顺序，数据库可能按任意物理存储顺序返回行。如果没写 ORDER BY，两次执行同一 LIMIT 查询可能拿到不同记录——尤其在有并发写入或表结构变更时。这不是 bug，是标准行为。
- 错误写法：
SELECT id, name FROM products LIMIT 5（下次执行可能返回完全不同的 5 条） - 正确写法：
SELECT id, name FROM products ORDER BY created_at DESC LIMIT 5 - 主键或唯一索引字段（如
id）是最常用于排序的字段，避免用无索引字段排序，否则性能陡降
分页场景下 OFFSET 越大越慢，替代方案有哪些
当 OFFSET 达到几万甚至几十万时，数据库仍需扫描并跳过前面所有行，即使只取 10 条，响应时间也会明显上升。这不是 LIMIT 本身的问题，而是 OFFSET 的实现机制决定的。
- 传统分页（
LIMIT 10 OFFSET 100000）：MySQL/PostgreSQL 都会全扫前 100010 行 - 游标分页（推荐）：用上一页最后一条的排序字段值作为条件，例如
WHERE created_at - 注意：游标分页要求排序字段严格唯一且无 NULL；若用
created_at，需加id作第二排序字段防重复
SQL Server 和 Oracle 怎么实现类似 LIMIT 的效果
SQL Server 和 Oracle 原生不支持 LIMIT，但各有等效语法。强行用 LIMIT 会直接报错 Incorrect syntax near 'LIMIT'（SQL Server）或 ORA-00933: SQL command not properly ended（Oracle）。
- SQL Server（2012+）：
SELECT * FROM orders ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY - Oracle（12c+）：
SELECT * FROM orders ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY - 旧版 Oracle（ROWNUM，但要注意
ROWNUM在ORDER BY之前生效，必须两层嵌套才能正确排序后截取
实际业务里，最容易被忽略的是游标分页中排序字段的唯一性保障——哪怕加了索引，如果允许 created_at 重复且没补 id，翻页就可能漏数据或重复。
