SQL入门：分页查询-原理、优化与实战

分页查询是 SQL 处理大量数据时的核心技术，通过限制单次返回记录数量，平衡查询效率与用户体验。标准 SQL 虽未统一分页语法，但主流数据库均通过扩展实现，核心逻辑围绕 “控制起始位置与返回行数” 展开。以下从基础原理、实现方式、优化策略及常见问题四个维度详细解析。

一、分页查询的核心原理与必要性

当表数据量达到万级以上时，一次性返回全部记录会导致：

• 数据库 IO 压力激增，查询耗时延长；
• 网络传输冗余数据，浪费带宽；
• 前端渲染卡顿，用户体验下降。

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

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

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

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

不同数据库的分页语法存在差异，但核心逻辑一致，以下是主流数据库的实现方式：

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_time DESC  -- 分页必须配合ORDER BY，否则顺序随机
LIMIT 0, 10;-- 第3页，每页10条（offset=20，取10条）
SELECT * FROM orders 
ORDER BY order_time DESC 
LIMIT 20, 10;  -- 等价于 LIMIT 10 OFFSET 20（推荐后者，语义更清晰）

简化写法：LIMIT row_count OFFSET offset

SELECT * FROM products 
ORDER BY price ASC 
LIMIT 10 OFFSET 30;  -- 第4页，每页10条

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

PostgreSQL 完全支持 MySQL 的分页语法，同时支持更灵活的扩展（如结合FETCH）：

-- 第2页，每页15条（offset=15）
SELECT * FROM users 
ORDER BY register_time DESC 
LIMIT 15 OFFSET 15;

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

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

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

低版本兼容（2008 及以下）：

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

-- 第3页，每页10条（取31-40条）
SELECT TOP 10 * FROM orders 
WHERE order_id NOT IN (SELECT TOP 30 order_id FROM orders ORDER BY order_id DESC  -- 排除前30条
)
ORDER BY order_id DESC;

4. Oracle：ROWNUM（低版本）与 OFFSET ... FETCH（12c+）

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

Oracle 12c+ 写法：

-- 第4页，每页25条（offset=75）
SELECT * FROM employees 
ORDER BY hire_date ASC
OFFSET 75 ROWS 
FETCH NEXT 25 ROWS ONLY;

Oracle 11g 及以下写法：

通过两层子查询生成行号并筛选范围：

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

三、分页查询的性能优化（重点解决大偏移量问题）

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

1. 用 “基于主键的范围查询” 替代大偏移量（OFFSET）

若表有自增主键（如id）或唯一排序字段（如order_time + 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  -- 利用主键索引快速定位，无需扫描前9990条
ORDER BY id DESC 
LIMIT 10;

优势：通过索引直接定位起始位置，查询时间与页码无关（无论第几页，耗时相近）。适用场景：支持 “上一页 / 下一页” 导航，无需直接跳转到任意页（如移动端列表）。

2. 为排序字段建立索引

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

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

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

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

-- 查询“2024年订单”并分页
SELECT * FROM orders 
WHERE order_time >= '2024-01-01' 
ORDER BY order_time DESC 
LIMIT 10 OFFSET 20;-- 复合索引：先过滤条件，再排序
CREATE INDEX idx_orders_time_filter ON orders(order_time DESC) 
WHERE order_time >= '2024-01-01';  -- 部分索引，进一步优化

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

SELECT *返回所有字段，增加数据传输和内存消耗。仅返回必要字段，甚至可通过 “索引覆盖查询”（字段全在索引中，无需回表）提升性能：

优化前：

SELECT * FROM products  -- 返回冗余字段
ORDER BY price DESC 
LIMIT 10 OFFSET 100;

优化后：

SELECT product_id, name, price  -- 仅返回必要字段
FROM products 
ORDER BY price DESC 
LIMIT 10 OFFSET 100;-- 建立包含查询字段的索引，触发索引覆盖
CREATE INDEX idx_products_price ON products(price DESC, product_id, name);

4. 避免实时计算总页数（COUNT(*) 优化）

显示 “总页数” 需计算总记录数（COUNT(*)），但大表上COUNT(*)耗时极长（需扫描全表）。

优化方案：

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

四、常见问题及解决方案

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

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

解决方案：

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

2. 排序字段不唯一导致顺序错乱

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

解决方案：增加唯一字段兜底，确保排序唯一：

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

3. 大偏移量查询超时

问题：OFFSET 1000000 需扫描并丢弃前 100 万条记录，耗时极长。

解决方案：

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

五、总结

分页查询的核心是 “分段获取数据”，不同数据库语法虽有差异，但优化思路一致：

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