SQL入门：分页查询核心技术解析

分页查询是 SQL 中处理大量数据展示的核心技术，通过限制单次返回的记录数量，提升高查询效率并提升用户体验。标准 SQL 中分页逻辑的实现因数据库而异，但核心思路一致：通过 “起始位置 + 获取数量” 或 “偏移量 + 限制行数” 控制返回结果。以下从基础原理、主流数据库实现、优化技巧及常见问题四个维度详解分页查询。

一、分页查询的核心原理

当表中数据量过大（如百万级），一次性查询所有记录会导致：

• 数据库 IO 压力激增，查询耗时变长；
• 传输大量冗余数据，浪费网络资源；
• 前端渲染卡顿，影响用户体验。

分页查询通过 **“分段获取数据”** 解决上述问题，核心参数包括：

• 页码（pageNum）：当前需要获取的页码（如第 1 页、第 2 页）；
• 每页条数（pageSize）：每页展示的记录数量（如每页 10 条、20 条）；
• 偏移量（offset）：从第几条记录开始获取（计算方式：offset = (pageNum - 1) * pageSize）。

例如：查询第 3 页数据（pageNum=3，pageSize=10），需从第 21 条记录开始（offset=20），获取 10 条数据。

二、主流数据库的分页实现方式

标准 SQL 并未定义统一的分页语法，不同数据库通过扩展关键字实现，常见方式如下：

1. MySQL / MariaDB：LIMIT 关键字（最常用）

MySQL 使用LIMIT offset, row_count语法，其中：

• offset：偏移量（从 0 开始，可选，默认从第 0 条开始）；
• row_count：需要返回的记录数。

基本用法：

-- 查询第1页，每页10条（offset=0，取10条）
SELECT * FROM orders 
ORDER BY order_date DESC  -- 分页必须配合ORDER BY，否则顺序随机
LIMIT 0, 10;-- 查询第3页，每页10条（offset=20，取10条）
SELECT * FROM orders 
ORDER BY order_date DESC 
LIMIT 20, 10;  -- 等价于 LIMIT 10 OFFSET 20

简化写法：LIMIT row_count OFFSET offset（语义更清晰）

SELECT * FROM orders 
ORDER BY order_date DESC 
LIMIT 10 OFFSET 20;  -- 与上例效果一致

2. PostgreSQL：LIMIT + OFFSET（兼容 MySQL）

PostgreSQL 支持与 MySQL 相同的LIMIT offset, row_count语法，同时也支持LIMIT row_count OFFSET offset，用法完全一致：

-- 查询第2页，每页20条（offset=20）
SELECT * FROM products 
ORDER BY price DESC 
LIMIT 20 OFFSET 20;

3. SQL Server：OFFSET ... ROWS FETCH NEXT ... ROWS ONLY（SQL Server 2012+）

SQL Server 2012 及以上版本支持标准 SQL 的分页语法，需配合ORDER BY使用：

-- 查询第2页，每页15条（offset=15）
SELECT * FROM users 
ORDER BY register_date DESC
OFFSET 15 ROWS  -- 跳过前15条
FETCH NEXT 15 ROWS ONLY;  -- 获取接下来的15条

低版本兼容写法（SQL Server 2008 及以下）：

使用TOP关键字结合子查询（效率较低，不推荐）：

-- 查询第2页，每页10条（通过子查询先排除前10条，再取前10条）
SELECT TOP 10 * FROM orders 
WHERE order_id NOT IN (SELECT TOP 10 order_id FROM orders ORDER BY order_date DESC
)
ORDER BY order_date DESC;

4. Oracle：ROWNUM 伪列（低版本）或 OFFSET ... FETCH（12c+）

Oracle 的分页实现分版本：

• Oracle 12c 及以上：支持OFFSET ... FETCH（与 SQL Server 一致）；
• 低版本（11g 及以下）：需通过ROWNUM伪列结合子查询实现。

Oracle 12c+ 写法：

-- 查询第3页，每页20条（offset=40）
SELECT * FROM employees 
ORDER BY hire_date DESC
OFFSET 40 ROWS 
FETCH NEXT 20 ROWS ONLY;

Oracle 11g 及以下写法：

通过两层子查询，先排序并标记行号，再筛选行号范围：

-- 查询第2页，每页10条（行号11-20）
SELECT * FROM (-- 内层子查询：排序并标记行号（ROWNUM）SELECT t.*, ROWNUM AS rn FROM (SELECT * FROM orders ORDER BY order_date DESC) tWHERE ROWNUM <= 20  -- 上限：第20条
) 
WHERE rn > 10;  -- 下限：第11条（>10）

5. 通用兼容方案：子查询 + 行号筛选（适用于所有数据库）

若需跨数据库兼容，可通过 “生成行号 + 筛选行号范围” 实现分页，核心步骤：

1. 为每条记录生成连续行号（结合ORDER BY确保顺序）；
2. 筛选行号在[(pageNum-1)*pageSize + 1, pageNum*pageSize]范围内的记录。

示例（通用逻辑）：

-- 查询第2页，每页10条（行号11-20）
SELECT * FROM (-- 生成行号（不同数据库生成方式不同）SELECT *, ROW_NUMBER() OVER (ORDER BY order_date DESC) AS row_num  -- 标准窗口函数生成行号FROM orders
) t
WHERE row_num BETWEEN 11 AND 20;  -- 筛选行号范围

• 说明：ROW_NUMBER()是标准窗口函数，支持 PostgreSQL、SQL Server、Oracle 12c+、MySQL 8.0+，低版本数据库需替换为对应行号生成方式（如 Oracle 的ROWNUM）。

三、分页查询的性能优化（重点）

分页查询的性能瓶颈主要体现在 **“大偏移量”场景（如LIMIT 1000000, 10），此时数据库需扫描前 1000010 条记录后才能返回结果，耗时极长。优化核心是“减少扫描的数据量”**。

1. 避免使用大偏移量（OFFSET），改用 “基于主键的范围查询”

若表有自增主键（如id）或唯一排序字段（如order_date + id），可通过 “上一页最后一条记录的主键” 定位下一页起始位置，替代OFFSET：

优化前（大偏移量，低效）：

-- 查询第1000页，每页10条（offset=9990，需扫描9990+10条）
SELECT * FROM orders 
ORDER BY id DESC 
LIMIT 10 OFFSET 9990;

优化后（基于主键范围，高效）：

假设上一页最后一条记录的id为 10000，则下一页从id < 10000开始取 10 条：

SELECT * FROM orders 
WHERE id < 10000  -- 利用主键索引快速定位
ORDER BY id DESC 
LIMIT 10;  -- 无需偏移，直接取前10条

优势：通过WHERE id < 10000利用主键索引，避免全表扫描，查询时间与偏移量无关（无论第几页，耗时相近）。

适用场景：

• 有唯一排序字段（如自增主键、唯一时间戳）；
• 仅需 “上一页 / 下一页” 功能，无需直接跳转到任意页（如移动端列表）。

2. 为排序字段建立索引

分页查询必须配合ORDER BY（否则记录顺序随机，分页无意义），若排序字段无索引，数据库会执行 “全表扫描 + 文件排序”，耗时极长。

优化方案：为ORDER BY后的字段建立索引，例如：

-- 为排序字段建立索引
CREATE INDEX idx_orders_date ON orders(order_date DESC);-- 分页查询会利用索引，避免全表扫描
SELECT * FROM orders 
ORDER BY order_date DESC 
LIMIT 10 OFFSET 20;

进阶：若查询包含WHERE条件，可建立 “条件 + 排序” 的复合索引，例如：

-- 查询“2024年订单”并按日期排序分页
SELECT * FROM orders 
WHERE order_date >= '2024-01-01' 
ORDER BY order_date DESC 
LIMIT 10 OFFSET 20;-- 建立复合索引（WHERE字段在前，ORDER BY字段在后）
CREATE INDEX idx_orders_date_filter ON orders(order_date DESC) 
WHERE order_date >= '2024-01-01';  -- 部分索引，进一步优化

3. 减少返回字段，避免SELECT *

SELECT *会返回所有字段，增加数据传输和内存消耗，尤其大表分页时影响显著。应只返回需要的字段，若字段较少，甚至可通过索引覆盖查询（无需回表）。

优化前：

SELECT * FROM products  -- 返回所有字段，低效
ORDER BY price DESC 
LIMIT 10 OFFSET 100;

优化后：

SELECT product_id, product_name, price  -- 只返回必要字段
FROM products 
ORDER BY price DESC 
LIMIT 10 OFFSET 100;-- 若字段全在索引中，可触发索引覆盖查询（性能极致）
CREATE INDEX idx_products_price ON products(price DESC, product_id, product_name);

4. 预估总页数时，避免全表计数（COUNT (*)）

分页场景常需显示 “总页数”（如 “共 100 页”），但COUNT(*)在大表上执行缓慢（需扫描全表）。

优化方案：

• 用近似值替代：如 MySQL 的EXPLAIN预估行数（rows字段），或 PostgreSQL 的reltuples（表统计信息）；
• 异步更新总计数：通过定时任务（如每小时）计算总条数并缓存，而非实时查询；
• 省略总页数：仅显示 “上一页 / 下一页”，不显示总页数（如移动端常见设计）。

四、常见问题及解决方案

1. 分页结果重复或缺失（数据实时变化导致）

问题：若分页过程中表数据发生插入 / 删除，会导致前后页记录重复或缺失（如第 1 页查询后新增 1 条记录，第 2 页会包含第 1 页的最后一条）。

解决方案：

• 用 “快照读” 查询：在事务中执行分页（如BEGIN; SELECT ...; SELECT ...; COMMIT;），确保前后页基于同一数据快照；
• 基于唯一字段分页：用WHERE id > 上一页最大id（而非OFFSET），避免数据变化影响（前提是id递增）。

2. 大偏移量查询耗时过长（如LIMIT 1000000, 10）

问题：OFFSET本质是 “跳过前 N 条记录”，数据库需扫描并丢弃前 N 条，偏移量越大，耗时越长。

解决方案：

• 改用 “基于主键的范围查询”（见优化技巧 1）；
• 限制最大页码：如最多显示前 100 页，超过则提示 “数据过多，请缩小范围”；
• 用游标（Cursor）：数据库游标可在服务器端维护分页状态，避免重复扫描（适合后端服务，不适合前端直接调用）。

3. 排序字段不唯一导致分页顺序错乱

问题：若ORDER BY的字段存在重复值（如多个订单日期相同），分页时可能出现同一条记录在不同页的情况（数据库对重复值的排序是随机的）。

解决方案：

• 为排序字段增加唯一字段兜底，确保排序唯一，例如：

-- 用“order_date + id”确保排序唯一（id是主键，唯一）
SELECT * FROM orders 
ORDER BY order_date DESC, id DESC  -- 增加id兜底
LIMIT 10 OFFSET 20;

五、总结

分页查询的核心是通过 “限制返回行数 + 控制起始位置” 实现数据分段，不同数据库语法虽有差异，但优化思路一致：

1. 优先用 “基于主键的范围查询” 替代大偏移量OFFSET，提升性能；
2. 为排序字段建立索引，避免全表扫描和文件排序；
3. 减少返回字段，利用索引覆盖查询进一步优化；
4. 处理数据实时变化：通过事务快照或唯一排序字段确保分页一致性。

合理的分页策略能显著降低数据库压力，同时提升用户体验，是处理大数据量查询的必备技能。