mysql用limit offset, count，postgresql用limit count offset offset；offset越大越慢因需扫描丢弃前n行，游标分页可优化。
MySQL 和 PostgreSQL 里 LIMIT 的写法差异
MySQL 和 PostgreSQL 都支持 LIMIT，但语法位置和参数含义不完全一致。MySQL 允许 LIMIT offset, count，而 PostgreSQL 要求 LIMIT count OFFSET offset —— 顺序反了，写错会直接报错。
- MySQL：
SELECT * FROM users LIMIT 10, 20表示跳过前 10 行，取 20 行 - PostgreSQL：
SELECT * FROM users LIMIT 20 OFFSET 10才等价；LIMIT 10, 20是语法错误 - SQLite 两者都支持，但推荐用
LIMIT count OFFSET offset写法，更可移植 - SQL Server 不支持
LIMIT，得用OFFSET ... FETCH NEXT（SQL Server 2012+）
分页时 OFFSET 越大越慢的根本原因
OFFSET 不是“跳到第 N 行”，而是“逐行扫描并丢弃前 N 行”。当 OFFSET 100000 时，数据库仍要定位、读取、过滤掉前 10 万行，再返回后续结果 —— 索引可能失效，I/O 和 CPU 成倍增长。
- 典型现象：第 1 页很快，第 500 页查询耗时从 20ms 涨到 2s+
- 如果排序字段有索引（如
ORDER BY created_at DESC），可以用“游标分页”替代OFFSET：记录上一页最后一条的created_at值，下一页查WHERE created_at -
LIMIT本身不慢，慢的是OFFSET的实现方式；别迷信“加索引就能救OFFSET”
在 ORM 中安全使用 limit() 和 offset()
ORM（如 Django ORM、SQLAlchemy、TypeORM）封装了底层 SQL，但容易掩盖分页陷阱。比如调用 .limit(10).offset(1000)，生成的仍是带 OFFSET 的语句，性能问题照旧。
- Django：
User.objects.all()[1000:1010]会转成LIMIT 10 OFFSET 1000，不是切片优化 - SQLAlchemy：
query.limit(10).offset(1000)同理；注意fetchmany()不等于分页，它只控制 fetch 大小 - TypeORM：
find({ skip: 1000, take: 10 })也是OFFSET，需手动改用游标逻辑 - 关键判断点：检查生成的 SQL 日志，确认是否真用了
OFFSET；别只看 ORM 方法名
用 LIMIT 1 做存在性检查时的常见误用
查“某条记录是否存在”，很多人写 SELECT COUNT(*) FROM table WHERE ... 或全字段 SELECT * 加 LIMIT 1。前者要扫全量匹配行，后者多传无用字段，都浪费资源。
- 正确做法：
SELECT 1 FROM table WHERE condition LIMIT 1—— 只返回一个常量，数据库可早停 - 别用
SELECT id代替SELECT 1，万一id是 NULL 或没索引，可能影响执行计划 - 某些场景下，
EXISTS (SELECT 1 FROM ...)比LIMIT更语义清晰，且优化器通常处理得更好 - 注意：
LIMIT 1不保证返回哪一行，仅用于“至少有一行”判断；别依赖其结果顺序或内容
分页真正难的不是写对 LIMIT 和 OFFSET，而是意识到它们只是“看起来像分页”的语法糖——底层没有跳转能力，只有扫描和丢弃。一旦数据量上去，这个假设就崩了。
