MySQL分页踩坑实录：LIMIT分页出现重复数据，同一主键ID跨页重复完美解决

最近在开发企业合同管理系统的列表分页功能时，我碰到了一个非常典型且棘手的MySQL分页问题：使用常规LIMIT做分页查询，第一页和第二页竟然出现了完全相同的主键ID数据，直接导致前端页面展示重复、业务数据错乱。排查过程中也发现很多开发者都踩过这个坑，甚至不少线上项目都暗藏这个隐性bug，尤其多表关联、带聚合查询的分页场景，问题更容易出现。

结合实战场景，我把问题根源、排查思路和终极解决方案完整整理出来，不仅能解决当前的重复数据问题，还能帮大家彻底规避这类分页陷阱，后续写分页SQL直接套用规范即可，新手也能快速上手。

🚨 问题复现：模拟业务场景的问题SQL

为了方便大家理解和复现，我重新编写了一段**简短sql，**还原分页重复的核心故障，这段SQL的问题和原始业务SQL完全一致，更简洁易懂，适合通用学习：

java 复制代码

-- 问题SQL：LIMIT分页出现主键ID跨页重复
SELECT
  coi.id,
  coi.create_time,
  coi.contract_name,
  coi.contract_code,
  coi.contract_amount
FROM contract coi
WHERE coi.del_flag = 0
-- 按合同主键分组
GROUP BY coi.id
-- 🔴 核心错误：无意义MAX聚合 + 单一时间字段排序，无唯一性
ORDER BY MAX(coi.create_time) DESC
-- 分页查询第二页
LIMIT 10, 10

业务场景说明 ：查询合同列表，每页展示10条数据，关联付款表统计已付未付金额，关联客户表拼接客户名称，第一页用LIMIT 0,10、第二页用LIMIT 10,10查询，结果主键id重复出现在两页，数据完全一致，业务端展示错乱。

核心故障点：排序仅依赖非唯一的create_time字段，还多加了无用的MAX聚合函数，没有唯一字段兜底，触发MySQL不稳定隐式排序，最终导致分页数据重复。

❌ 根源剖析：为什么会出现分页重复？

1. 排序规则无唯一性，是核心元凶

这段SQL的致命问题就在排序语句：ORDER BY MAX(coi.create_time) DESC，结合MySQL底层排序机制，拆解问题如下：

聚合函数完全多余：SQL已经按主键coi.id分组，每组只有一条主表记录，MAX(coi.create_time)和直接使用coi.create_time效果完全一样，不仅没用，还会干扰数据库执行计划；
单一时间字段不唯一：create_time是创建时间，批量导入、高并发新增、定时任务生成数据时，极易出现多条记录create_time完全相同，少则几条，多则几十条，业务场景无法避免；
MySQL隐式排序不稳定 ：当排序字段值重复时，MySQL不会固定顺序，而是按照数据物理存储位置、内存读取地址等隐式规则随机排序，每次查询的排序结果都可能变；
LIMIT分页依赖固定排序：LIMIT是基于排序后的结果集截取数据，排序不稳定就会导致同一条数据，这次在第一页，下次就被分到第二页，出现跨页重复。

2. 高频疑问：同一时间有上10条以上的数据，加上主键ID，还会出现重复吗？

这里明确给出答案：绝对不会！

主键（PRIMARY KEY）是数据库强制约束，自带唯一索引和非空校验，数据库会严格保证每条记录主键ID全局唯一，绝不重复，插入重复主键会直接报错，这也是我们后续用主键做兜底排序的核心依托。哪怕同一时间创建100条数据，主键ID也各不相同，完全可以用来固定排序。

3. 通用误区：只按时间排序，全是隐性隐患

很多开发者写分页，习惯性只写ORDER BY create_time DESC，小数据量、测试环境下问题不显现，一旦上线后数据量增大、批量操作变多，同时间数据增多，分页重复、数据漏查、顺序错乱问题一定会爆发，属于典型的"线下没问题，线上必踩坑"。

✅ 终极解决方案：固定排序规则，加主键兜底

修复核心思路

分页查询想要稳定不重复，核心原则：ORDER BY字段组合必须唯一 。最优方案就是业务排序字段 + 主键ID，先用时间排序，再用唯一主键做二次兜底，彻底杜绝排序不稳定问题。

修复后的完整正确SQL

无需改动查询逻辑和关联关系，仅优化排序语句，即可彻底解决分页重复问题，修改后SQL如下，核心优化处已标注：

java 复制代码

-- 问题SQL：LIMIT分页出现主键ID跨页重复
SELECT
  coi.id,
  coi.create_time,
  coi.contract_name,
  coi.contract_code,
  coi.contract_amount
FROM contract coi
WHERE coi.del_flag = 0
-- 按合同主键分组
GROUP BY coi.id
-- 🟢 核心优化：去掉无意义MAX，增加主键ID兜底排序
ORDER BY coi.create_time DESC, coi.id DESC
-- 分页查询第二页，结果稳定无重复
LIMIT 10, 10

关键修改点详解

💡

移除无意义MAX聚合函数：按主键分组后，直接用coi.create_time排序，简化SQL，提升执行效率；

新增主键ID二次排序：ORDER BY coi.create_time DESC, coi.id DESC，时间相同的记录，按主键ID固定顺序，每次查询结果完全一致；

排序顺序不影响结果：主键ID升序、降序均可，推荐降序，贴合数据创建先后逻辑，可读性更强。

📌 MySQL分页排序通用规范（永久避坑）

经过这次实战踩坑，总结一套通用分页排序规范，不管是单表查询，还是多表关联、聚合计算的复杂分页，严格遵循即可彻底告别数据重复、漏查问题：

严禁单一非唯一字段单独排序：禁止单独用create_time、update_time、状态、金额等非唯一字段排序；
排序必须加唯一字段兜底：首选"业务字段 + 主键ID"组合，主键天然唯一，无需额外加索引，无性能损耗；
避免无用聚合函数参与排序：分组后单条记录，无需用MAX/MIN/SUM等聚合函数做排序，冗余且影响效率；
大数据量分页优化：千万级数据避免深度LIMIT偏移，改用主键ID范围查询，性能大幅提升。

通用正确排序模板（直接复制）

复制代码

-- 按创建时间分页（最常用） ORDER BY create_time DESC, id DESC 
-- 按更新时间分页 ORDER BY update_time DESC, id DESC 
-- 多业务字段+主键分页 ORDER BY contract_code DESC, create_time DESC, id DESC

🧐 实战常见疑问解答

1. 为什么之前没遇到这个问题？

测试环境数据量小，同时间创建数据极少，隐式排序刚好没错位；上线后高并发、批量操作多，同时间数据增多，问题立刻暴露，属于隐性线上bug。

2. 加主键排序会影响查询性能吗？

几乎无性能损耗！主键本身就是默认索引，MySQL二次排序直接利用主键索引，效率和单一时间排序几乎无差别，用极小成本换稳定性，性价比极高。

📝 文章总结

MySQL分页出现重复数据，99%的原因都是排序字段不唯一，这是最经典也最容易被忽略的分页陷阱。

解决办法极其简单：写分页ORDER BY时，务必加上唯一主键ID做兜底，养成"业务字段+主键"的排序习惯，不管是简单分页还是复杂聚合分页，都能彻底解决重复、漏查、错乱问题。

如果你的项目里，也有只按时间、状态等单一字段排序的分页SQL，建议尽快优化，提前规避线上故障！

原创不易，这篇是实战踩坑干货，觉得有用欢迎点赞、收藏、关注，后续持续分享更多MySQL实战优化、后端开发避坑技巧～