ThinkPHP排序导致分页混乱的实战解决教程

ThinkPHP分页混乱这事儿，说白了，十有八九不是分页本身写错了，而是排序没控住。没加 ORDER BY，或者加了但索引没对上、字段重复、参数丢了……只要把这几个点卡死，基本就能稳住。

先说第一个核心：必须显式写 order()，而且得放在 select 前面。 paginate() 不会自动给你补排序，你要是不写 order，那排序就相当于交给 MySQL 随机决定了。翻页的时候数据跳动、重复、漏条，全是这个埋的坑。

• ✅ 正确写法：User::order('id desc')->paginate(15)，或者稳妥一点用多维排序 User::order(['create_time' => 'desc', 'id' => 'desc'])->paginate(15)
• ❌ 错误写法：User::paginate(15)（没排序）、User::select()->paginate(15)（这等于先把数据查出来，然后退化成内存切片翻页，效率低还容易乱）
• 多表关联的时候，order 字段必须带上表别名，比如 ->join('profile p', 'user.id = p.user_id')->order('p.sort desc')，不然 MySQL 直接报错“Column 'sort' is ambiguous”。

接着看第二个点：排序字段必须建索引，顺序也得匹配。 拿 EXPLAIN 看一下，如果出现 Using filesort，就说明 MySQL 没用上索引排序，而是临时开了个内存表来排序——性能差不说，翻页也容易错乱。

• 有个常见的坑：where 条件写了 where('status', 1)，order 用了 order('create_time desc')，但数据库里只给 status 建了单列索引。正确做法是建联合索引 (status, create_time)，顺序不能反。
• 游标分页（cursorPaginate）要求排序字段严格非空、单调、可比较。主键 id 天然满足这个要求，create_time 就得设成 NOT NULL DEFAULT '1970-01-01'，并且配上 (create_time, id) 的联合索引。
• 还要注意，别在排序字段上加函数，比如 orderRaw("DATE(create_time) desc") 或者 whereRaw("YEAR(create_time) = ?")，这种写法规避了索引，直接让性能掉档。

第三个问题：筛选条件要跟着分页一起透传。 点第二页，地址栏变成 ?page=2，但 start_time、keyword 全丢了？这不是 bug，是 paginate 默认只读取 page 参数。

• 安全的写法：->paginate(15, false, ['query' => array_filter(request()->only(['start_time', 'end_time', 'status', 'keyword']))])，只传你需要的参数。
• 千万别图省事写 ['query' => request()->param()]，这会把 token、_csrf 这些敏感参数也带过去，安全问题不是闹着玩的。
• 模板里渲染分页，就用 {$list->render()}，别自己拼 URL 或者用 {$page|raw}。

最后是高并发下的时间戳重复问题。create_time 相同的订单一多，ORDER BY create_time DESC LIMIT 10 OFFSET 20 这种写法就可能跳过某些记录，尤其是翻页到后面的时候，问题更明显。

• 解决办法很简单：复合排序兜底，->order('create_time desc, id desc')，保证每条记录排序值唯一。
• 更好的方案是改用游标分页 User::order('id desc')->cursorPaginate(20)，基于主键排序，天然稳定，也没有 offset 带来的性能衰减。
• 还要注意，NULL 值必须处理。要么数据库层设 create_time NOT NULL，要么写入时补一个默认值。不处理的话，cursorPaginate 会报错或者行为异常。