ThinkPHP分页避坑：分页查询中order by字段不唯一导致的翻页重复

先说一个结论：在ThinkPHP的分页查询中，如果ORDER BY字段不唯一，翻页时出现数据重复几乎是必然的。这不是框架本身的Bug，而是MySQL在特定场景下的“确定性谜题”。

ThinkPHP分页时 ORDER BY 字段不唯一，为什么翻页会重复？

根源在于MySQL对ORDER BY + LIMIT查询采用优先队列优化，而优先队列的堆排序是不稳定的。当排序字段的值存在重复时，每次查询时记录的相对顺序就变得不可预测。

举个例子：你写了->order('status desc, updated_at desc')，但假设有多条记录的status和updated_at完全相同。MySQL在取LIMIT 10,10时，很可能把上一次排在第9位的记录“安排”到了第11位。结果呢？这条记录既出现在第1页的末尾，又出现在第2页的开头。

这个问题不可能在PHP层面解决——必须从SQL逻辑上堵住这个漏洞。

TP5/6 中如何补全排序字段确保唯一性？

解决方案其实很简单：在所有分页查询的->order()链最后，强制追加主键（或业务中绝对唯一的字段），作为“决胜排序项”。

• TP5 写法示例：->order('sort_order desc, id desc')
• TP6 写法示例：->orderBy('sort_order DESC')->orderBy('id DESC')
• 如果主键是复合主键（如(user_id, log_time)），那就都写上：->order('created_at desc, user_id desc, log_time desc')
• 不要依赖“默认按主键排”——只要ORDER BY没有显式声明主键，MySQL就不保证顺序的确定性

哪些字段组合容易踩坑？

以下常见排序写法在真实数据中极易触发重复问题，值得特别留意：

• 只用时间字段：->order('created_at desc')。同一秒插入多条记录的情况太常见了
• 只用状态+时间：->order('status asc, updated_at desc')。审核中状态+同秒更新的订单经常会扎堆出现
• 用计算字段或表达式：->order('IFNULL(score, 0) desc')。大量NULL或相同分数会导致排序不稳定
• 关联查询后排序：->join('user')->order('user.level desc')。level字段通常是枚举值，重复率极高

核心判断标准很简单：只要任意两条记录在你写的全部ORDER BY字段上完全一致，就已经进入了不稳定排序的“雷区”。

为什么加了索引也不一定能解决问题？

加索引确实能加速排序，比如创建KEY idx_status_updated (status, updated_at)这样的组合索引。但必须认清一点：索引解决的是排序效率，而不是排序的确定性。

关键在于：

• 索引本身依赖索引字段组合在每行都唯一才能保证顺序稳定。如果索引字段存在重复值，索引内部的等值区间里，物理存储顺序仍然不可控
• 如果排序字段没有覆盖索引最左前缀——比如索引是(a,b)，却只ORDER BY b——那索引排序根本用不上，直接进入filesort阶段，结果更加不确定
• 真正可靠的方案只有一种：让ORDER BY的整个字段列表在逻辑上构成唯一排序键

所以排查问题时，不要只盯着“有没有加索引”，先确认“排序结果在数学上是否可确定”。这个逻辑捋清了，分页重复的问题自然迎刃而解。