分页功能通过offset和limit截取数据实现。1.分页核心是计算偏移量（offset=(页码-1)每页条数）和限制数量；2.使用sql的limit子句或数据库特定语法（如sql server的offset…fetch next）执行查询；3.前端传页码和每页大小，后端计算偏移量并执行查询，同时通过count()获取总记录数以计算总页数；4.优化超大数据量时可采用游标分页（基于主键或时间戳）、子查询结合索引覆盖、或数据库内置分页函数（如row_number()）；5.非sql场景可用搜索引擎的from/size参数，但需注意深度分页性能问题。
分页功能的核心在于从大量数据中按需截取特定部分进行展示。说白了，就是通过计算你想要看的数据从哪里开始（偏移量，OFFSET）以及看多少条（限制数量，LIMIT），来精确地从数据库中取出那一“页”数据。这就像你翻书，知道要翻到第几页，以及每页有多少行字。
解决方案
实现分页功能，最直接也最常用的方式就是利用SQL数据库的LIMIT子句（在MySQL、PostgreSQL等）或类似的机制（如SQL Server的OFFSET...FETCH NEXT）。
基本思路是：
确定每页显示的数据量（pageSize）：这是个固定值，比如每页10条、20条。获取当前请求的页码（pageNumber）：用户想看第几页。计算数据起始位置（offset）：这是关键。公式通常是 offset = (pageNumber - 1) * pageSize。举例：如果每页10条，用户请求第1页，offset = (1 - 1) * 10 = 0。用户请求第2页，offset = (2 - 1) * 10 = 10。用户请求第N页，offset = (N - 1) * pageSize。
然后，将这个offset和pageSize代入SQL查询：
SELECT *FROM your_tableORDER BY some_column -- 必须有排序，否则结果顺序不确定LIMIT pageSize OFFSET offset;
或者更常见的写法：
SELECT *FROM your_tableORDER BY some_columnLIMIT offset, pageSize; -- 注意：MySQL中是 (offset, count)，即从offset开始取count条
在实际应用中，前端通常会发送pageNumber和pageSize到后端API。后端接收这两个参数，计算出offset，执行SQL查询，并将查询结果连同总记录数（通常需要另一个COUNT(*)查询）一起返回给前端。前端拿到数据后，就可以渲染当前页的内容，并根据总记录数和pageSize计算出总页数，显示分页导航。
分页查询为什么需要总记录数？
这问题问得挺实在的，我刚开始做分页的时候也纳闷，为啥非得查个总数呢？直接给数据不就得了。但后来才明白，这总记录数（totalCount）对于用户体验和前端逻辑来说，简直是不可或缺的。
你想啊，一个用户打开一个列表页，他想知道“我到底有多少条数据可以看？”、“我现在在第几页？”、“还有多少页没看完？”。如果没有总记录数，前端就无法计算出总页数，也就无法展示“总共X页”或者“前往第N页”这样的导航条。用户只能机械地点击“下一页”，直到数据没了，这种体验是很糟糕的。
从技术层面看，这个totalCount通常是通过一个独立的SELECT COUNT(*)查询来获取的。比如：
SELECT COUNT(*) FROM your_table WHERE your_conditions;
这个查询通常会和分页查询一起执行，或者在第一次加载时获取并缓存。不过，这里就引出了一个老生常谈的性能问题：对于数据量特别大的表，COUNT(*)可能会非常慢，因为它需要扫描符合条件的所有记录。这就像你要统计一个图书馆里有多少本书，如果每一本都要拿出来数一遍，那可真是个体力活。
所以，在面对超大规模数据时，是否需要精确的totalCount，以及如何获取它，就需要我们权衡了。有时候，为了性能，我们可能会牺牲一点精确性，比如只显示“下一页”按钮，或者给出一个近似的总数。这就像电商网站的商品列表，你可能不会看到精确到个位的商品总数，而是“约XX万件商品”。
如何优化超大表的分页查询性能？
LIMIT offset, count这种分页方式，在数据量小的时候非常方便，但在面对几百万、几千万甚至上亿条记录的表时，offset值越大，查询效率就会急剧下降。这是因为数据库在处理LIMIT offset, count时，仍然需要扫描并跳过offset数量的记录，才能开始真正地获取count条数据。想象一下，你从一堆牌里找第10000张牌，你得把前面9999张都翻过去。
优化超大表分页查询性能，有几个策略可以考虑，它们各有优缺点，适用场景也不同：
基于主键或唯一索引的“游标”式分页（Cursor-based Pagination）这是我个人非常推崇的一种方式，尤其适用于“下一页/上一页”的场景，或者无限滚动加载。它的核心思想是：不使用OFFSET，而是记录上一页最后一条数据的某个唯一标识（比如ID或时间戳），然后下一页的查询就从这个标识之后开始。
例如，假设你的表有一个自增的id列：
第一页：SELECT * FROM your_table ORDER BY id ASC LIMIT 20;第二页（假设第一页最后一条数据的ID是100）：SELECT * FROM your_table WHERE id > 100 ORDER BY id ASC LIMIT 20;这种方式的优点是：无论翻到第几页，查询效率都非常高，因为它直接利用了索引进行范围查找，避免了全表扫描和跳过大量记录。缺点：无法直接跳到任意页（比如不能直接跳到第500页），只能“向前”或“向后”翻页。这对于需要展示总页数和页码导航条的场景不太适用。
子查询优化 LIMIT + 索引覆盖当必须使用LIMIT offset, count，且ORDER BY的字段有索引时，可以尝试这种优化。原理是先在子查询中利用索引快速定位到主键，然后通过主键关联回原表获取所有列的数据。
SELECT t.*FROM your_table tINNER JOIN ( SELECT id FROM your_table ORDER BY your_indexed_column LIMIT offset, count) AS subquery ON t.id = subquery.id;
这种方式在某些数据库和特定场景下，性能会比直接LIMIT好很多，因为它避免了在主查询中对大量数据进行排序和跳过。子查询只获取了少量的主键，再通过主键快速查找，效率更高。
利用数据库的特定分页函数（如SQL Server的ROW_NUMBER()）某些数据库提供了更高级的分页功能，比如SQL Server的ROW_NUMBER()或OFFSET...FETCH NEXT。这些功能通常在内部做了优化，比手动计算OFFSET更高效。
例如，SQL Server 2012+ 的 OFFSET...FETCH NEXT：
SELECT *FROM your_tableORDER BY your_columnOFFSET offset ROWS FETCH NEXT count ROWS ONLY;
这种方式语法更简洁，且数据库通常会对其进行优化。
而ROW_NUMBER()则可以更灵活地处理复杂排序和分组分页：
SELECT *FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY your_column) AS rn FROM your_table) AS subqueryWHERE rn BETWEEN start_row_number AND end_row_number;
这里的start_row_number和end_row_number也是基于页码和每页大小计算出来的。
除了LIMIT，还有哪些常见的数据库分页策略？
除了LIMIT这种最直观的方式，数据库世界里实现分页的策略其实挺多的，它们各有各的哲学和适用场景。
基于窗口函数的分页（如ROW_NUMBER()、RANK()、DENSE_RANK()）这在SQL Server、Oracle、PostgreSQL等数据库中非常常用，尤其是在需要更复杂的排序或分组分页时。窗口函数能够为结果集中的每一行分配一个唯一的、基于指定排序的序号。
比如，你想按某个字段排序后，取出第X到第Y条数据：
SELECT your_columnsFROM ( SELECT your_columns, ROW_NUMBER() OVER (ORDER BY order_column ASC) AS rn FROM your_table WHERE your_conditions) AS subqueryWHERE rn BETWEEN ((page_number - 1) * page_size + 1) AND (page_number * page_size);
ROW_NUMBER()会为每一行分配一个不重复的序号，即使order_column的值相同。RANK()和DENSE_RANK()则在处理相同值时有所不同（RANK()会跳过序号，DENSE_RANK()不会）。这种方式非常灵活，可以结合分区（PARTITION BY）实现分组内的分页，比如“每个部门工资最高的5个人”。
数据库特定的分页语法不同的数据库系统有自己独特且优化的分页语法。
SQL Server: 前面提到的 OFFSET N ROWS FETCH NEXT M ROWS ONLY，这是SQL Server 2012之后推荐的分页方式，简洁高效。Oracle: 以前常用的是嵌套子查询和ROWNUM伪列，但现在更推荐使用OFFSET/FETCH或者ROW_NUMBER()。老式写法：
SELECT * FROM ( SELECT a.*, ROWNUM rn FROM ( SELECT * FROM your_table ORDER BY your_column ) a WHERE ROWNUM = start_row_number;
新式写法（Oracle 12c+）：
SELECT *FROM your_tableORDER BY your_columnOFFSET offset ROWS FETCH NEXT count ROWS ONLY;
基于搜索/索引引擎的分页（如Elasticsearch、Solr）对于全文搜索或大数据分析场景，我们通常会使用专门的搜索/索引引擎。这些引擎有自己的分页机制，通常是from和size参数，功能上类似于SQL的OFFSET和LIMIT。例如，Elasticsearch的查询体：
{ "from": 0, "size": 10, "query": { "match_all": {} }}
但需要注意的是，这些引擎通常对“深度分页”（即from值非常大）有性能限制或默认上限，因为它们内部实现可能与传统关系型数据库不同，深度分页会消耗大量资源。对于深度分页，它们更推荐使用scroll API或search_after（类似于前面提到的游标分页）。
选择哪种分页策略，往往取决于你的数据库类型、数据量大小、查询复杂度以及前端需要怎样的分页体验。没有银弹，只有最适合你当前场景的方案。
以上就是分页功能如何实现？LIMIT与页码计算的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/153394.html
微信扫一扫 
支付宝扫一扫 
