using filesort出现是因为排序字段未被索引覆盖或索引顺序不匹配；游标分页需游标字段有索引且排序方向与索引一致；paginate本身不引发filesort，关键在索引设计与查询条件对齐。
为什么EXPLAIN里总出现Using filesort
分页查询中出现Using filesort，不是ThinkPHP写错了，而是MySQL发现排序字段没走索引——哪怕你写了order('create_time desc')，只要create_time不在WHERE条件覆盖的索引里，或者索引顺序不匹配，它就只能临时排序。
常见诱因包括：
• where('status', 1)->order('create_time desc')，但只建了(status)单列索引
• where('user_id', $uid)->order('id desc')，但没给id建索引（主键除外）
• 复合查询中order字段在联合索引里位置靠前，但WHERE没用到最左字段
验证方式：调用$query->getLastSql()拿到真实SQL，前面加EXPLAIN执行，重点看type是否为range或ref、key是否命中你建的索引名、Extra是否还有Using filesort。
游标分页必须配什么索引
游标分页（如where('id', '>', $lastId)->order('id ASC')->limit(20)）能绕过OFFSET，但前提是id字段必须有索引，且排序方向和索引方向一致。否则MySQL仍会回表或触发Using filesort。
实操要点：
• 主键id天然带聚簇索引，直接可用，无需额外操作
• 若用create_time做游标字段，必须建(create_time, id)联合索引（防时间重复），且order方向要和索引顺序一致（如索引是ASC，就不能order('create_time DESC')）
• 不要对游标字段做函数处理，比如whereRaw('DATE(create_time) > ?')会让索引完全失效
• last_id参数必须校验为非负整数，否则SQL注入风险直接暴露
paginate()里怎么关掉filesort隐患
paginate()本身不控制索引使用，它只是封装了LIMIT和OFFSET。真正决定是否Using filesort的是你传进去的查询条件和数据库索引设计。
能做的实际动作：
• 显式指定field()，只查必要字段，减少排序时的内存开销
• 把order字段纳入WHERE所用的联合索引中，例如常用where('status', 1)->order('create_time desc')，就建(status, create_time)索引
• 避免在paginate()前加with()再order()，关联预加载后排序可能无法下推到主表，导致临时表+filesort
• 禁用总数统计：paginate(20, false)，虽然不解决filesort，但至少省掉一次COUNT全表扫描的叠加影响
复合条件分页时索引怎么建才不踩坑
多个WHERE + ORDER组合下，索引字段顺序错一位，整个索引就废一半。别按“感觉”排，按查询模式排。
典型场景与索引建议：
• where('category_id', 5)->where('status', 1)->order('create_time desc') → 建(category_id, status, create_time)，create_time放最后，支持范围排序
• where('user_id', $uid)->order('id desc') → 建(user_id, id)，不是(id, user_id)，否则user_id等值条件无法利用索引有序性
• where('name', 'like', 'abc%')->order('score desc') → 建(name, score)，左模糊可走索引前缀，score才能用于排序
• 已有(a, b)联合索引，就别再单独建(a)，MySQL 5.7+会忽略冗余索引
最容易被忽略的一点：游标分页的WHERE条件字段和ORDER字段必须同时出现在同一个联合索引里，且顺序严格对应；否则即使数据量不大，Using filesort也会悄悄回来。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
