AJAX调用时MySQL查询返回重复结果，SQL Fiddle无法复现

看起来你在开发通知系统的分页功能时遇到了头疼的问题：AJAX加载下一页时出现重复数据，但在SQL Fiddle里却复现不出来——这种环境差异导致的bug确实挺磨人的，我来帮你梳理下可能的原因和解决办法：

1. 排序字段不唯一是最常见的元凶 #

你提到结果需要按pr...排序（推测是priority或者create_time这类字段），如果这个排序字段存在重复值，MySQL的排序就会变得不稳定：每次执行查询时，相同排序值的记录顺序可能随机变化，导致OFFSET分页时出现重复或跳过数据。

解决办法：在排序条件中追加一个唯一键（比如通知表的ID），让排序逻辑绝对稳定。举个例子：

-- 原来的排序（可能不稳定）
ORDER BY priority DESC

-- 修改后的稳定排序
ORDER BY priority DESC, notification_id DESC

这样即使多条通知优先级相同，也会按唯一的ID排序，分页的结果顺序就不会乱了。

2. 前端AJAX的OFFSET参数计算错误 #

检查你的前端分页逻辑：有没有可能每次请求下一页时，OFFSET的数值计算出错？比如第一页OFFSET是0，第二页应该是10，但如果代码里不小心把OFFSET重复设置成0，或者页码计算错误（比如页码从0开始却用page*10计算），就会重复加载同一页数据。

验证方式：打开浏览器的开发者工具，查看每次AJAX请求发送的OFFSET参数，确认它是按0、10、20...这样递增的。

3. 分页请求之间数据发生了变动 #

如果在两次AJAX请求的间隙，有新通知插入、旧通知被删除或者排序字段被修改，就会导致OFFSET对应的“位置”发生偏移。比如：

• 第一次请求加载了OFFSET 0-9的10条数据
• 这时候插入了一条优先级更高的通知，所有旧通知的“位置”都往后移了一位
• 第二次请求OFFSET 10时，会加载到原来的OFFSET 9-18的数据，导致重复出现原来的第10条数据

解决办法：改用基于游标的分页替代OFFSET分页。比如记住上一页最后一条数据的priority和notification_id，下次查询时用这些值作为条件：

SELECT n.* FROM notifications n
JOIN your_other_tables ...
WHERE priority <= :last_priority 
  AND notification_id < :last_notification_id
ORDER BY priority DESC, notification_id DESC
LIMIT 10

这种方式完全不受数据变动的影响，不会出现重复或跳过的问题。

4. SQL Fiddle和生产环境的数据差异 #

SQL Fiddle里的数据量可能太小，或者排序字段没有重复值，所以复现不出问题。你可以在本地环境模拟大量测试数据：比如插入20条以上priority相同的通知，然后多次执行分页查询，看是否会出现重复结果。

内容的提问来源于stack exchange，提问作者Andrei