必须使用ORDER BY确保分页稳定性，否则OFFSET/LIMIT结果不可靠；JOIN加剧性能下降，宜用游标分页或子查询先分页主表；窗口函数可绕过OFFSET但物化成本高。
ORDER BY 必须存在，否则 OFFSET/LIMIT 结果不可靠
MySQL 和 PostgreSQL 都不保证无 ORDER BY 时的行顺序，哪怕表有主键或索引。你看到的“自然顺序”只是巧合，分页跳转后数据重复或丢失非常常见。
- JOIN 后的结果集没有隐式排序依据，
OFFSET 10 LIMIT 20可能每次返回不同行 - 即使加了
ORDER BY id，若id不唯一（比如多表 JOIN 出现重复id），排序仍不稳定 - 正确做法是用确定性、高选择性的组合排序，例如
ORDER BY t1.id, t2.created_at
JOIN + LIMIT OFFSET 在大偏移量下性能断崖式下降
数据库执行 LIMIT 10000, 20 时，仍需扫描前 10020 行并丢弃前 10000 行——JOIN 放大会让这个代价更重，尤其涉及多表关联和非覆盖索引时。
- PostgreSQL 中，
OFFSET越大，EXPLAIN显示的Rows Removed by Filter越多 - MySQL 8.0+ 对
LIMIT有优化，但 JOIN 后无法利用索引下推，效果有限 - 替代方案：用游标分页（
WHERE id > ? ORDER BY id LIMIT 20），要求排序字段严格单调且有索引
LEFT JOIN 与 INNER JOIN 对分页结果数量的影响差异极大
分页逻辑必须基于最终结果集行数，而不同 JOIN 类型会改变这个基数——这直接影响 LIMIT 截取的是“多少条记录”，而非“多少个主表实体”。
-
INNER JOIN：结果行数 ≤ 主表行数；分页按实际联查行计数，通常符合直觉 -
LEFT JOIN：主表一行可能对应从表多行，导致结果行数远超主表；LIMIT 20可能只覆盖主表前 3 条记录 - 若目标是“每页展示 20 个用户及其订单”，应先分页主表（
SELECT id FROM users ORDER BY id LIMIT 20 OFFSET 40），再用IN或JOIN查详情
MySQL 8.0+ 的窗口函数可绕过 OFFSET，但要注意物化成本
ROW_NUMBER() OVER (ORDER BY ...) 能实现逻辑分页，避免 OFFSET 扫描，但它是先生成全量序号再过滤，内存和临时表压力不小。
- 示例：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY u.id) rn FROM users u LEFT JOIN orders o ON u.id = o.user_id) t WHERE t.rn BETWEEN 101 AND 120 - 该写法在小数据量下清晰，但若 JOIN 后结果达百万行，子查询会强制物化，比传统 OFFSET 更慢
- 仅推荐用于排序字段高度选择性、且总结果集可控（
分页不是加个 LIMIT 就完事的事——JOIN 放大了排序不确定性、行数误判和执行路径退化。最容易被忽略的是：你以为在分页“用户”，其实数据库在分页“用户×订单”的笛卡尔积片段。
