MySQL中LIMIT offset, count写法简洁但仅限MySQL/SQLite支持，跨数据库应统一用LIMIT count OFFSET offset；必须配合ORDER BY保证结果稳定，大OFFSET性能差，推荐游标分页优化。
MySQL的LIMIT offset, count写法直接但不通用
MySQL允许把偏移量和行数写在同一个LIMIT子句里，比如LIMIT 20, 10表示跳过前20行、取接下来10行。这种写法简洁，但仅MySQL和SQLite支持，PostgreSQL、Oracle、SQL Server等全部报错。
常见错误现象：ERROR: LIMIT #,# syntax is not supported —— 这是PostgreSQL明确拒绝该语法的提示。
- 偏移量
offset从0开始，LIMIT 0, 10等价于取前10行 - 如果
offset超出总行数，查询返回空结果集，不会报错 - 该写法在拼接动态SQL时容易出错：比如页码变量没做校验，
page=0导致LIMIT -10, 10语法错误
PostgreSQL必须用LIMIT count OFFSET offset显式拆分
PostgreSQL不接受逗号分隔的双参数形式，强制要求OFFSET单独成词、且必须放在LIMIT之后。例如LIMIT 10 OFFSET 20才是合法写法，语义与MySQL的LIMIT 20, 10完全一致。
使用场景中要注意：很多ORM（如Django、SQLAlchemy）底层会自动适配，但手写原生SQL或对接老系统时，若直接把MySQL SQL迁过来，必定失败。
-
OFFSET值可以为0，LIMIT 10 OFFSET 0和LIMIT 10等价 -
OFFSET不能为负数，否则报syntax error at or near "-" - 当
OFFSET极大（如几百万），性能会急剧下降——因为PG仍需扫描并跳过前面所有行
跨数据库兼容写法只能选LIMIT ... OFFSET ...
如果你的项目要同时支持MySQL和PostgreSQL（比如用Flyway管理多环境迁移，或中间件路由不同DB），唯一安全的写法是统一用LIMIT count OFFSET offset。MySQL 5.5+ 和所有新版都支持该语法，且语义完全一致。
容易踩的坑：有人误以为“MySQL兼容PostgreSQL写法”，于是把LIMIT 10 OFFSET 20当标准，却忽略MySQL旧版本（如5.0）不支持——不过这类版本早已退出主流支持周期。
- 不要混用：避免
LIMIT 10, 20 OFFSET 5这类非法组合，任何数据库都不认 - 计算
OFFSET时注意页码起始：第1页对应OFFSET 0，第N页对应OFFSET (N-1) * page_size - 高偏移分页建议改用游标分页（
WHERE id > ? ORDER BY id LIMIT ?），而非依赖OFFSET
分布式或无序表上LIMIT结果不稳定是共性问题
无论是MySQL还是PostgreSQL，只要查询没带ORDER BY，LIMIT返回哪几行都是不确定的——这点常被忽略。尤其在分布式PostgreSQL（如Hologres、Citus）或未建索引的大表上，多次执行SELECT * FROM t LIMIT 10 OFFSET 100可能拿到重复或遗漏的记录。
这不是语法差异，而是执行模型决定的：没有排序保证，数据库可按任意物理顺序返回行。
- 必须加
ORDER BY才能让分页结果可重现，例如ORDER BY created_at DESC, id - 复合排序字段最好包含唯一列（如
id），避免created_at重复导致排序不稳定 - 即便加了
ORDER BY，大偏移+深分页依然慢；真正海量数据应优先考虑基于游标的方案
