分页查询通过限定起始位置和数量实现，核心是OFFSET与LIMIT或OFFSET FETCH语法，需配合ORDER BY确保顺序；不同数据库如MySQL用LIMIT OFFSET，SQL Server和Oracle新版本支持OFFSET FETCH，旧版则依赖ROWNUM或ROW_NUMBER()；深分页性能差因数据库需扫描跳过大量数据，优化策略包括使用游标分页、索引排序列、避免频繁计算总数及选择性查询字段。
SQL SELECT 如何实现分页查询？这问题，说白了，就是如何从一大堆数据里，挑出你想要的那一小段，然后还能告诉数据库“从第几条开始，给我多少条”。核心思想就是限定结果集的数量和起始位置。这在任何需要展示列表数据的地方都太常见了，比如电商网站的商品列表、博客的文章列表，甚至后台管理系统里的用户列表。如果一次性把所有数据都丢给前端，那用户体验和服务器压力都会是个灾难。所以，分页查询，是数据库操作里一个绕不开，也必须掌握的基础技能。
解决方案
实现分页查询，不同数据库有不同的惯用手法，但万变不离其宗，都是围绕“偏移量”和“限制数量”这两个核心概念。
最常见且直观的方式，是使用
LIMIT
和
OFFSET
子句。这在 MySQL、PostgreSQL 和 SQLite 中非常流行。
SELECT column1, column2 FROM your_table ORDER BY some_column -- 排序是分页的前提，否则结果集顺序不确定 LIMIT page_size OFFSET offset_value;
这里的
page_size
是你每页想要显示多少条数据，
offset_value
则是从结果集的第几条记录开始取。举个例子，如果你想获取第二页的10条数据（每页10条），那么
offset_value
就是
(2 - 1) * 10 = 10
。
对于 SQL Server 2012 及更高版本，以及 Oracle 12c 及更高版本，它们引入了更符合标准 SQL 的
OFFSET ... FETCH NEXT ... ROWS ONLY
语法，这使得分页的表达更加清晰：
SELECT column1, column2 FROM your_table ORDER BY some_column OFFSET offset_value ROWS FETCH NEXT page_size ROWS ONLY;
而在 SQL Server 的早期版本，或者在需要更复杂逻辑时，我们可能会用到
ROW_NUMBER()
窗口函数。这是一种更灵活，但写起来也更“重”一点的方法：
SELECT column1, column2 FROM ( SELECT column1, column2, ROW_NUMBER() OVER (ORDER BY some_column) as rn FROM your_table ) AS subquery WHERE rn > offset_value AND rn <= (offset_value + page_size);
Oracle 数据库在早期也常常使用
ROWNUM
伪列结合子查询来实现分页，但它的语义有些特殊，需要小心处理。现在有了
OFFSET ... FETCH
，已经很少直接用
ROWNUM
来做分页了。
无论哪种方式，记住一点：排序是分页的基础。没有明确的
ORDER BY
子句，数据库返回的记录顺序是不确定的，每次查询可能拿到不同的“第一页”或“第二页”，这显然是不可接受的。
分页查询为什么需要优化？它和全表扫描有什么区别？
说实话，刚开始写代码的时候，我可能根本没想过分页还要“优化”这回事，能跑起来就行。但随着数据量蹭蹭上涨，用户抱怨页面加载慢，你就会发现，简单的
LIMIT OFFSET
并不是万能药。
分页查询之所以需要优化，核心原因在于性能。当你的表里只有几百几千条数据时，
LIMIT 10 OFFSET 1000
也许感觉不到什么，但如果数据量达到几百万、几千万，甚至上亿，你再尝试
LIMIT 10 OFFSET 1000000
，数据库可能会让你等到花儿都谢了。
它和全表扫描的区别，首先在于目的。全表扫描是为了获取表中的所有数据，或者至少是扫描所有数据来找到符合条件的数据。而分页查询，它的目的是只获取数据的一个子集。理论上，分页查询应该比全表扫描快得多，因为它只需要读取一部分数据。
但问题就出在
OFFSET
上。当你指定
OFFSET N
时，数据库在内部通常需要扫描 N +
LIMIT
条记录，然后丢弃前面的 N 条，只返回后面的
LIMIT
条。想象一下，如果你要取第100万页的第10条数据（每页10条），数据库可能需要扫描并跳过将近1000万条数据，才能找到你真正想要的10条。这和全表扫描的开销已经非常接近了，甚至在某些情况下，因为额外的排序和跳过操作，可能比直接扫描前N条数据更慢。这就是所谓的“深分页”问题。
所以，优化分页查询，很大程度上就是为了避免或缓解深分页带来的性能损耗。我们希望数据库能直接跳到我们想要的数据块，而不是一步步地数过去。
不同数据库系统在实现分页查询时有哪些常见的语法差异？
实践中，我们很少只盯着一个数据库用，所以了解不同数据库的分页语法差异，是很有必要的。这就像你去不同城市，虽然都说中文，但方言总有些不同。
-
MySQL / PostgreSQL / SQLite： 这是最“亲民”的组合，都支持
LIMIT
和
OFFSET
。
-- MySQL/PostgreSQL/SQLite SELECT * FROM products ORDER BY id LIMIT 10 OFFSET 20;
或者在 MySQL 中，你也可以写成
LIMIT 20, 10
，但这种写法在其他数据库中不通用，容易混淆，我个人不太推荐。
-
SQL Server： SQL Server 的分页语法经历了几次演变。 旧版本 (SQL Server 2008 R2 及更早)： 常用
ROW_NUMBER()
结合子查询。
SELECT id, name FROM ( SELECT id, name, ROW_NUMBER() OVER (ORDER BY id) as rn FROM products ) AS PagedResults WHERE rn BETWEEN 21 AND 30; -- 获取第3页，每页10条
这种方式比较通用，但也相对繁琐。 新版本 (SQL Server 2012 及更高)： 引入了
OFFSET ... FETCH NEXT ... ROWS ONLY
，这让分页变得非常简洁和标准化。
SELECT id, name FROM products ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY; -- 获取第3页，每页10条
我发现很多开发者会更偏爱这种语法，因为它更清晰地表达了“跳过多少行，取多少行”的意图。
-
Oracle： Oracle 的分页历史也很有趣。 旧版本 (Oracle 11g 及更早)： 主要是利用
ROWNUM
伪列，但
ROWNUM
的特性让直接使用它进行分页有些棘手，因为它是在查询结果集生成时动态分配的，你不能直接
WHERE ROWNUM > 10
。通常需要嵌套子查询来解决。
SELECT * FROM ( SELECT ROWNUM AS rn, id, name FROM ( SELECT id, name FROM products ORDER BY id ) WHERE ROWNUM <= 30 -- 先取前30条 ) WHERE rn > 20; -- 再从这30条里取第21-30条
这种写法，稍微不注意就容易出错，或者理解起来比较费劲。 新版本 (Oracle 12c 及更高)： 和 SQL Server 类似，也引入了
OFFSET ... FETCH NEXT ... ROWS ONLY
。
SELECT id, name FROM products ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY; -- 获取第3页，每页10条
所以，如果你在用较新的数据库版本，
OFFSET ... FETCH
这种标准化的写法会是首选，它不仅代码可读性好，而且通常数据库的优化器也能更好地处理它。
在实际应用中，如何选择最适合的分页策略并避免常见的性能陷阱？
选择分页策略，这真不是一道选择题，更像是一道权衡题。没有银弹，只有最适合你当前场景的方案。
首先，考虑你的数据库类型和版本。这是最基础的。如果你的数据库支持
OFFSET ... FETCH
，那通常是首选，因为它清晰、标准，且数据库厂商会对其进行优化。
其次，数据量和访问模式。这是决定你是否需要更高级分页策略的关键。
- 小数据量或只访问前几页： 简单的
LIMIT OFFSET
- 大数据量且用户可能访问深层页面： 这就是深分页的“重灾区”了。此时，
LIMIT OFFSET
会成为性能杀手。
常见的性能陷阱和避免方法：
-
深分页的
OFFSET
陷阱： 正如前面所说，
OFFSET
越大，性能越差。 解决方案：
- 基于游标（Keyset Pagination）或“下一页”分页： 这是最推荐的深分页解决方案。它不使用
OFFSET
，而是利用上一次查询的最后一条记录的某个唯一标识（通常是主键或带索引的排序列）来定位下一页的起始位置。 例如，假设你的产品表有一个自增
id
列，并且你总是按
id
排序：
-- 获取第一页（ID > 0） SELECT id, name FROM products WHERE id > 0 ORDER BY id LIMIT 10; -- 用户点击下一页，假设上一页最后一条记录的ID是 100 SELECT id, name FROM products WHERE id > 100 ORDER BY id LIMIT 10;
这种方式的优点是，数据库可以直接利用索引快速定位到
id > 100
的位置，而不需要扫描前面的100条记录。缺点是不能直接跳到任意页（比如第50页），只能一页一页地翻，更适合“加载更多”或“下一页”的交互模式。
- 基于游标（Keyset Pagination）或“下一页”分页： 这是最推荐的深分页解决方案。它不使用
-
ORDER BY
列没有索引： 无论你用哪种分页方式，
ORDER BY
子句都是必不可少的。如果排序列没有索引，数据库为了排序，可能需要对整个结果集进行文件排序（filesort），这会消耗大量的CPU和I/O资源。 解决方案： 确保
ORDER BY
中使用的列（或列组合）有合适的索引。
-
频繁计算总页数： 很多分页界面会显示“共 X 页”或“共 Y 条记录”。要获取总记录数，通常需要执行一个
COUNT(*)
查询：
SELECT COUNT(*) FROM your_table WHERE your_conditions;
如果这个
COUNT(*)
查询没有被索引覆盖，它也可能导致全表扫描，成为新的性能瓶颈。尤其是在每次翻页都去查一次
COUNT(*)
的情况下。 解决方案：
- 缓存总数： 对于变化不频繁的数据，可以缓存总数。
- 异步加载总数： 先加载第一页数据，然后异步加载总数，或只在用户需要时才显示。
- 估算总数： 对于非常大的表，可以接受一个大致的总数估算，而不是精确值。
- 特定场景优化： 某些数据库（如PostgreSQL）在某些情况下，
COUNT(*)
可能比你想象的快，因为它可能利用了 MVCC 快照。但这不是普遍规则。
-
*不必要的 `SELECT
：** 只查询你需要的列，而不是
SELECT *
。这减少了网络传输和数据库内部处理的数据量。虽然对分页本身的影响可能不如
OFFSET` 那么大，但这是一个良好的习惯，能有效提升整体性能。
在实际项目中，我通常会这样考虑：对于后台管理系统，数据量相对可控，用户对深分页的访问频率不高，
OFFSET ... FETCH
或
LIMIT OFFSET
配合索引就足够了。但对于面向用户的前端应用，尤其是那些数据量巨大、用户可能频繁滚动的场景，我会优先考虑基于游标的分页，或者至少在
OFFSET
达到一定阈值时，切换到更高效的策略。这需要你在设计之初就有所规划，而不是等到出问题了才来补救。
mysql oracle 前端 大数据 区别 性能瓶颈 异步加载 前端应用 代码可读性 为什么 sql mysql count select 堆 异步 sqlite oracle postgresql 数据库