MySQL和PostgreSQL的LIMIT语法不同：MySQL支持LIMIT offset,count和LIMIT count OFFSET offset，而PostgreSQL仅支持后者；OFFSET过大导致性能下降，因需扫描并丢弃前N行，建议改用游标分页。
LIMIT 本身不慢，慢的是 OFFSET；分页查第 100 页（每页 20 条）时，数据库仍要扫描并丢弃前 1999 行——这不是“加个索引就能解决”的问题。
MySQL 和 PostgreSQL 的 LIMIT 语法差异必须写对
MySQL 支持两种写法：LIMIT 10, 20（跳过 10 行取 20 行）和 LIMIT 20 OFFSET 10，二者等价；PostgreSQL 只认 LIMIT 20 OFFSET 10，不支持逗号写法。SQLite 两者都支持，但用 LIMIT count OFFSET offset 更可移植。
常见错误现象：
- 在 PostgreSQL 里写
LIMIT 10, 20→ 报错syntax error at or near "," - 在 MySQL 里把
OFFSET写在LIMIT前面 → 语法错误 - ORM（如 SQLAlchemy）生成的语句默认用
OFFSET，但你没注意方言配置，上线后在 PG 环境直接失败
ORDER BY 缺失时，LIMIT 返回结果不可靠
没 ORDER BY 的 LIMIT 不是分页，只是随机抽样。数据库可能每次返回不同行，尤其在并发写入或 MVCC 场景下。
使用场景：
- 调试时快速看几条数据：可以不用
ORDER BY，但得心里清楚这只是临时观察 - 接口返回、前端分页、导出预览：必须带确定性排序，比如
ORDER BY id ASC或ORDER BY created_at DESC - 子查询中用了
LIMIT，但外层没ORDER BY→ 结果顺序无法保证，JOIN 后可能错乱
性能影响：没有索引的排序字段会触发 filesort，LIMIT 无法提前终止；有索引时，执行计划里能看到 Using index; Using filesort 或更优的 Using index。
OFFSET 超过 10000 就该换游标分页了
当 OFFSET 100000 时，数据库仍要定位、读取、过滤掉前 10 万行——即使 id 有主键索引，B+ 树也要遍历到对应叶子节点再跳过，I/O 和 CPU 开销陡增。
游标分页实操建议：
- 上一页最后一条记录是
id = 8000001，下一页查：SELECT * FROM users WHERE id > 8000001 ORDER BY id LIMIT 20 - 时间字段更常见：
WHERE created_at （注意方向匹配） - 复合游标（防重复/漏数据）：
WHERE (created_at, id) - 别用
UUID字段做游标主键，除非你确认它在业务写入时严格递增或有序
查“是否存在”别用 COUNT(*) 或 SELECT *
想确认某条记录存不存在，写 SELECT COUNT(*) FROM table WHERE condition 或 SELECT * FROM table WHERE condition LIMIT 1 都是次优解。
正确做法：
-
SELECT 1 FROM table WHERE condition LIMIT 1—— 只返回常量，优化器可早停，避免读取整行数据 -
EXISTS (SELECT 1 FROM table WHERE condition)—— 语义更清晰，多数引擎对 EXISTS 有专门优化 - 别写
SELECT id代替SELECT 1：万一id是 NULL 或没索引，执行计划可能退化
容易踩的坑：ORM 自动生成的 .exists() 方法底层未必真用 EXISTS，要看具体实现；Django 的 QuerySet.exists() 是安全的，但 TypeORM 的 count() 默认走 COUNT(*)。
真正难的不是写对 LIMIT，而是判断什么时候不该用它——比如深度分页、高并发列表、实时滚动加载，这些场景下 OFFSET 已经不是“语法问题”，而是架构约束。游标分页要配合前端传回的 last_id 或 cursor 值，服务端不能假设用户是从第 1 页开始翻的。
