limit分页通过sql的limit和offset子句实现，适用于中小型数据集。1.每页条数（page_size）与当前页码（page_number）决定offset值，offset=(page_number-1)*page_size；2.性能问题出现在offset值过大时，数据库需扫描大量记录再丢弃；3.解决办法包括避免深度分页、使用游标分页、添加合适索引；4.实际开发中建议封装分页函数或使用orm内置方法，并在api设计中合理限制参数。
分页功能是几乎所有涉及数据展示的系统中都绕不开的一个基础模块，尤其在 Web 应用、API 接口和后台管理系统中非常常见。实现分页的关键在于如何高效地从数据库中取出指定范围的数据，而 LIMIT 分页算法就是其中最常用的一种方式。
什么是 LIMIT 分页？
简单来说，LIMIT 分页指的是使用 SQL 中的 LIMIT 和 OFFSET 子句来控制查询返回的记录数量与起始位置。例如：
SELECT * FROM users ORDER BY id DESC LIMIT 10 OFFSET 20;
这条语句表示：按 id 降序排列用户表，跳过前 20 条记录，取接下来的 10 条。
这非常适合用于实现“第一页、第二页……”这样的分页逻辑，但它的性能表现和适用场景需要特别注意。
如何计算页码和偏移量？
要正确使用 LIMIT 分页，首先要理解两个关键参数：
- 每页条数（page_size）：你希望每页显示多少条数据。
- 当前页码（page_number）：用户正在看的是第几页。
它们之间的关系是：
offset = (page_number - 1) * page_size limit = page_size
举个例子，如果每页显示 10 条数据，想获取第 3 页的内容：
offset = (3 - 1) * 10 = 20
所以 SQL 就会是：
SELECT * FROM table LIMIT 10 OFFSET 20;
这种方式适用于大多数中小型数据集，但在大数据量或高并发下可能会出现性能问题。
LIMIT 分页的性能问题
虽然 LIMIT + OFFSET 使用起来简单直接，但它并不是万能的。主要问题出现在当 offset 值很大时，比如：
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 OFFSET 100000;
这个时候数据库仍然需要扫描前 100000 条记录，再丢弃掉，只返回最后 10 条。这会导致查询效率下降，尤其是在没有合适索引的情况下。
解决办法有几个方向：
- 避免深度分页：比如限制只能翻到前几十页，或者提供搜索/筛选代替无休止翻页。
- 使用基于游标的分页（Cursor-based Pagination）：通过上一页最后一条记录的唯一标识（如 ID 或时间戳）来定位下一页起点，避免使用 OFFSET。
- 添加合适的索引：确保排序字段有索引，这样数据库可以快速定位起始点。
实际开发中的建议
在实际开发中，我们通常会封装一个通用的分页函数，接受 page_number 和 page_size 作为参数，然后自动计算 offset 并生成对应的 SQL 查询。
以下是一个简单的 python 示例：
def paginate(page_number, page_size): offset = (page_number - 1) * page_size return f"LIMIT {page_size} OFFSET {offset}"
如果是使用 ORM（如 django、SQLAlchemy），一般都有内置的分页方法，比如 Django 的 Paginator，使用起来更方便也更安全。
另外，在构建 API 接口时，推荐将分页参数设计为可选，默认值合理，比如 page=1&size=20，并且对最大 size 做限制，防止恶意请求拖垮数据库。
总结
基本上就这些。LIMIT 分页的核心在于理解 offset 和 limit 的关系，以及它在不同数据规模下的表现。虽然它不是最高效的分页方式，但在绝大多数情况下已经足够好用了。只要注意不要过度依赖 deep pagination，就能很好地满足业务需求。
