MySQL的LIMIT OFFSET越往后越慢，是因为其必须扫描并丢弃前OFFSET行，即使有索引也无法直接跳转；优化应改用游标分页（如WHERE id > last_id），配合单调递增且有索引的排序字段及ORDER BY create_time DESC, id DESC防重复。
MySQL用LIMIT做分页时，OFFSET为什么越往后越慢
因为MySQL必须先扫描并跳过前OFFSET行数据，才能返回后续结果。当OFFSET很大（比如100万），即使只取10条，它仍要定位到第1000001行，期间所有被跳过的行都参与了索引遍历或全表扫描。
实际优化建议：
- 避免直接用
LIMIT 1000000, 20拉第100万页；改用基于游标的分页（如记录上一页最后的id值） - 确保
ORDER BY字段有索引，否则LIMIT前的排序成本会飙升 - 如果业务允许，限制前端最大页码（如只允许查前1000页），后端直接拒绝
OFFSET > 10000的请求
PostgreSQL里ROW_NUMBER()比OFFSET/LIMIT更灵活但要注意什么
ROW_NUMBER()是窗口函数，能按任意逻辑编号再过滤，适合复杂排序场景（比如按多字段+去重后分页）。但它需要完整计算整个结果集的序号，内存和CPU开销比LIMIT/OFFSET高。
典型写法：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC, id DESC) AS rn FROM orders WHERE status = 'paid' ) t WHERE t.rn BETWEEN 101 AND 120;
注意点：
- 子查询里的
ORDER BY必须明确，否则ROW_NUMBER()行为不确定 - 如果
WHERE条件没走索引，外层BETWEEN再快也救不了性能 - 不要在大表上无条件用
ROW_NUMBER() OVER ()——它会强制全表编号
SQL Server用OFFSET/FETCH怎么写才不报错
必须搭配ORDER BY，否则直接报错：Msg 102, Level 15, State 1, Line X: Incorrect syntax near 'OFFSET'。这是硬性语法要求，不是警告。
正确写法示例（查第51–60条）：
SELECT id, name FROM products ORDER BY id OFFSET 50 ROWS FETCH NEXT 10 ROWS ONLY;
常见误区：
- 漏写
ROWS关键字（OFFSET 50 ROWS不能简写为OFFSET 50） - 把
FETCH NEXT写成FETCH FIRST（虽然标准SQL支持，但SQL Server只认NEXT） - 在视图或内联表函数里用
OFFSET/FETCH时，外部再套ORDER BY可能触发重复排序，影响性能
Oracle 12c+用ROWNUM分页为什么容易漏数据
因为ROWNUM是在结果生成时逐行赋值的，且永远从1开始。写WHERE ROWNUM BETWEEN 11 AND 20永远返回空——第1行ROWNUM=1不满足>=11，被过滤；后续行永远拿不到ROWNUM >= 11的机会。
必须嵌套两层查询：
SELECT * FROM (
SELECT a.*, ROWNUM rnum FROM (
SELECT * FROM employees ORDER BY hire_date
) a WHERE ROWNUM = 11;
关键细节：
- 内层
WHERE ROWNUM 控制上限，外层rnum >= N切下界 - 中间的
ORDER BY必须在最内层子查询里，否则ROWNUM分配顺序和业务排序不一致 - Oracle 12c+推荐改用
OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY，语义清晰且优化器更友好
分页不是拼语法，核心是理解每种写法背后的数据访问路径。OFFSET大了慢、ROWNUM嵌套容易错、ROW_NUMBER()吃内存——这些都不是配置问题，而是执行计划层面的代价。上线前务必用EXPLAIN（或对应数据库的执行计划工具）看真实扫描行数。
