大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

上个月同一周来了两个投诉。运营说订单列表翻到第三页，看到了第一页的订单。财务说月度导出少了几十单，金额对不上。

一个多，一个少，看着是两件事。查到最后，问题都出在那句 SQL 上：`ORDER BY` 里只有一个不唯一的字段，翻页的那几秒里数据还在动。

这套导出脚本跑了两年，一直是对的。它就这么错了两年，没人发现，因为没人核对过顺序。

## 一、顺序不归你管

很多人把 `ORDER BY created_at DESC` 读成"按时间倒序"。准确的说法是：按时间倒序，时间相同的行之间没有约定。SQL 标准没规定同值行谁在前，MySQL 也没补一条，谁先谁后由执行计划决定。

执行计划会变。数据量涨了会变，统计信息更新了会变，加个筛选条件、改个索引、升个版本，都可能变。所以"排序不稳定"这句话，说得再准一点：顺序没有规则。没有规则的东西，没法用"再跑一次"去验证。

麻烦在于它平时很稳。`created_at` 上有索引，InnoDB 的二级索引叶子按"索引列 + 主键"有序。走索引扫描时，同值行恰好按主键排好，看着跟写了唯一键一样。测试环境一直对，多半就是这个原因。

哪次优化器改走 `filesort`，顺序立刻换一副样子。`filesort` 更不讲究，带 `LIMIT` 时它用优先队列，只维护前 N+M 行。同值行谁留下、谁被替换，没有任何对外承诺。

## 二、为什么两年都没事，突然就出事

两年前这张表一秒只落几条单，同一秒里基本没有并列。没有并列，顺序就是唯一的，怎么写都对。两年里数据涨上来了，批量导入一进来，同一秒几百条订单，并列出现了，问题才有机会露头。这一年表上还改过索引，也加过筛选条件，执行计划悄悄换过一次。三个变化叠在一起，就是"一直对，突然错"。不是脚本变了，是它脚下的东西变了。

翻页还有第二个麻烦，经常被混进来一起骂：你翻页的时候，数据在动。第一页拿完，有人新插了 5 条 `created_at` 更大的单，这 5 条挤到最前面，原来的第 21 行被推到第 26 位。第二页从第 21 行开始取，开头这 5 行就是第一页的结尾。反过来，期间删了 5 条，就跳过 5 条。这个叫翻页位移，列表页上它只是"看着别扭"，到了导出和对账，就是缺数据。

还有一层是主从。读写分离的库，分页查询落在从库上，从库延迟两秒，这两秒里的新行就看不到。这时候就算你补了唯一键，行集本身还是变了。所以稳定性分两层：排序稳定是 SQL 层的，数据一致是复制层的。这三件事里，只有排序能靠改 SQL 治，位移和延迟都得换取数方式。

## 三、复现：把计划换掉，看两批行

复现不用造复杂数据。一张一百万行的订单表，`created_at` 精确到秒，批量导入让同一秒塞进几百条。先看执行计划，同一条 SQL，用 hint 把两种计划分别固定下来：

```sql
-- 表结构（示意）
CREATE TABLE t_order_demo (
  id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  order_no VARCHAR(32) NOT NULL,
  status TINYINT NOT NULL,
  created_at DATETIME NOT NULL,
  KEY idx_created (created_at)
) ENGINE=InnoDB;

-- 走索引：Extra 是 Using index
EXPLAIN SELECT id, created_at FROM t_order_demo FORCE INDEX (idx_created)
ORDER BY created_at DESC LIMIT 20 OFFSET 40;

-- 退到排序：Extra 是 Using filesort
EXPLAIN SELECT id, created_at FROM t_order_demo IGNORE INDEX (idx_created)
ORDER BY created_at DESC LIMIT 20 OFFSET 40;
```

看 `Extra` 那一列。走索引时是 `Using index`，退到排序时是 `Using filesort`。走索引，顺序由索引定；退到 `filesort`，顺序由扫描顺序和排序算法定。两条计划各跑一次，把第 41 到 60 行的主键集合拿出来比对，对不上。

同一个计划跑一百次，结果都一样。换个计划，结果就换一批。所以判断这件事，别用"再跑一次对不对"，要看计划有没有变。

两页是不是同一批行，可以直接量。集合运算里，单个查询块带 `ORDER BY` 和 `LIMIT` 要加括号，不加直接报语法错。

```sql
-- 相邻两页有没有交集，正常应该为 0
SELECT COUNT(*) FROM (
  (SELECT id FROM t_order_demo ORDER BY created_at DESC LIMIT 20 OFFSET 20)
  INTERSECT
  (SELECT id FROM t_order_demo ORDER BY created_at DESC LIMIT 20 OFFSET 40)
) x;
```

`INTERSECT` 和 `EXCEPT` 是 MySQL 8.0.31 才有的，8.4 和 9.x 也支持。版本低就把两页结果落到临时表，再 `JOIN` 一下。还有一种误判要避开：页内的 `COUNT(*)` 和 `COUNT(DISTINCT id)` 在这类场景下永远相等，一页不会自己重复，重复只出现在跨页、跨次。量错了对象，报警永远不响。

## 四、三种改法，各治一段

补唯一键最省事。把排序改成 `ORDER BY created_at DESC, id DESC`，同值行之间就有了确定的先后。代价没有想象中大。InnoDB 的二级索引本来就带主键后缀，`KEY(created_at)` 反向扫描时天然满足 `created_at DESC, id DESC`。多数情况不用另建联合索引，先 `EXPLAIN` 看一眼 `Extra` 里有没有 `Using filesort` 再决定。真正需要组合索引的是另一种场景：排序前面还挂着筛选。比如 `WHERE status = 1 ORDER BY created_at DESC`，要让过滤和排序共用一条索引，才谈得上 `(status, created_at)`。补唯一键治并列，治不了翻页位移，也治不了主从延迟。

游标分页把"跳过前 M 行"换成"从上一页最后一行继续"。插入和删除都不会让行错位，代价是不能跳页，只能上一页下一页。

```sql
-- 第一页
SELECT id, created_at FROM t_order_demo
ORDER BY created_at DESC, id DESC
LIMIT 20;

-- 后续页：把上一页最后一行的 (created_at, id) 带进来
SELECT id, created_at FROM t_order_demo
WHERE (created_at, id) < ('2026-11-04 10:00:00', 88123456)
ORDER BY created_at DESC, id DESC
LIMIT 20;
```

`created_at` 如果允许 NULL，行比较会退化成三值逻辑，游标会漏行。业务上一般不允许为空，建表时顺手确认一次。游标这条要看 `EXPLAIN`：排序能靠索引后缀，范围落在两列上，走不了就把 `(created_at, id)` 建成联合索引。

主键区间适合对账、备份、跑批这类不需要页面的场景。按主键切块，每块固定大小，天然不重不漏。

```sql
-- 按主键切块导出，一块 5000 行
SELECT id, order_no, created_at FROM t_order_demo
WHERE id >= 1 AND id < 5001
ORDER BY id;

-- 下一块从上一块的上界继续
SELECT id, order_no, created_at FROM t_order_demo
WHERE id >= 5001 AND id < 10001
ORDER BY id;
```

按时间做增量导出时，条件不能写成 `created_at >= ? AND id > ?`。它会漏：边界之后 `created_at` 更新、但 id 比游标小的行，会被 `id > ?` 挡掉。

```sql
-- 对：两个字段一起推进
WHERE (created_at, id) > ('2026-11-04 10:00:00', 88123456)

-- 错：会漏掉 created_at 更新、id 更小的行
WHERE created_at >= '2026-11-04 10:00:00' AND id > 88123456
```

| 方案 | 治什么 | 能不能跳页 | 适合场景 | 代价 |
| --- | --- | --- | --- | --- |
| OFFSET + 唯一键 | 排序并列 | 能 | 后台列表、页数少 | 翻页位移还在，深页慢 |
| 游标分页 | 排序 + 位移 | 不能 | 信息流、无限滚动、导出 | 要带游标，接口得改 |
| 主键区间 | 排序 + 位移 | 不适用 | 对账、备份、跑批 | 只能顺序推进，不能按时间随机取 |

别把这件事跟"深翻页慢"混在一起。`OFFSET 100000` 慢是性能问题，解法是延迟关联或者游标。今天说的是结果不对：索引全在，SQL 也不慢，照样会重复。

## 五、上线前自检

给每个分页接口加一条自检，成本很低。同一条件跑两次，比对主键集合，差集不为空就报警。跑的时候挑没有写入的窗口，否则误报的是数据变化，不是排序。导出脚本更要做，导出的错不会有人当场发现，要等到对账。

自检不能拿一句 SQL 自己减自己，那永远是 0。要落两份快照：

```sql
CREATE TEMPORARY TABLE snap_a (id BIGINT PRIMARY KEY);
CREATE TEMPORARY TABLE snap_b (id BIGINT PRIMARY KEY);

-- 第一次导出后
INSERT INTO snap_a SELECT id FROM t_order_demo WHERE status = 1;

-- 隔一段时间，第二次导出后
INSERT INTO snap_b SELECT id FROM t_order_demo WHERE status = 1;

-- 正常应为 0，不为 0 说明两次拿到的不是同一批行
SELECT COUNT(*) FROM (
  SELECT id FROM snap_a
  EXCEPT
  SELECT id FROM snap_b
) d;
```

`EXCEPT` 的版本要求和 `INTERSECT` 一样，8.0.31 起。低版本换成 `LEFT JOIN`：

```sql
SELECT COUNT(*) FROM snap_a a
LEFT JOIN snap_b b ON a.id = b.id
WHERE b.id IS NULL;
```

顺带把索引过一遍。`EXPLAIN` 的 `Extra` 里有没有 `Using filesort`，`rows` 是不是比上个月大了一个量级。排序和过滤能不能共用一条索引，比多建一条索引更重要。主从环境再加一条：同一条 SQL 在主库和从库各跑一次，比主键集合，别只比条数。条数一样、行不一样，是最难发现的那种。

## 六、避坑清单

排序字段后面永远补一个唯一键，`id` 就行。补完先看计划，别急着建联合索引。这条改动小，收益是长期的，我现在的建表规范里固定写这一条。

跨页导出、对账、跑批，一律不要用 OFFSET。游标或者主键区间，选一个。写脚本的时候顺手加一条"两次结果一致"的断言，比事后查对账便宜得多。

最后一条是我自己踩的。有次做数据订正，我用 `LIMIT 1000 OFFSET n` 循环更新，跑了二十轮。跑完核对，有三批行被修了两遍，另有两批一次没碰。原因还是排序不唯一，加上订正过程本身改了数据。后来改成按主键区间推进，脚本开头先 `SELECT id` 拍一份快照。订正类脚本比查询更怕这个，它自己会改数据，错一次就留痕。

## 写在最后

分页不是"取第几页"，是"每次重新算一次前 N 行"。排序里有并列，这个"前 N 行"就不唯一。补个唯一键、换成游标，两行代码的事，能省掉一场对账。这套改法不挑库。换任何关系库，只要 `ORDER BY` 最后没有唯一键，翻页还是这个样子。

回到开头那两件事。导出脚本补了主键，又改成按主键切块；列表接口补了唯一键，翻到第三页不再撞见第一页。两个投诉，一套改法。

你们的分页接口，排序最后一段写的是什么？有没有过"翻页又看到同一条"？评论区说说，我按场景帮你看看是排序还是延迟。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋


上个月同一周来了两个投诉。运营说订单列表翻到第三页，看到了第一页的订单。财务说月度导出少了几十单，金额对不上。

MySQL分页结果重复怎么解决？排序稳定性与游标分页实战

同一周两个投诉：列表翻页重复、对账导出少单。把排序不唯一和翻页位移拆开讲，给出唯一键兜底、游标分页、主键区间三种改法，附可执行的上线自检 SQL。

数据库

分页查询排序不稳定导致重复和遗漏数据，根因是ORDER BY仅含非唯一字段且执行计划可变。解决需补唯一键（如id）、用游标或主键区间替代OFFSET，并上线自检比对主键集合。

代码解释

MySQL

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MySQL分页结果重复怎么解决？排序稳定性与游标分页实战-腾讯云开发者社区-腾讯云

MySQL分页结果重复怎么解决？排序稳定性与游标分页实战

MySQL分页结果重复怎么解决？排序稳定性与游标分页实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐