ThinkPHP排序慢主因是MySQL未走索引导致Using filesort，需按WHERE等值字段、范围字段、ORDER BY字段顺序建联合索引，order()须置于select()前，禁用paginate改用游标分页，并严格控制查询字段。
ThinkPHP 排序慢，多数不是 order() 写错了，而是底层 SQL 没走索引、字段没收敛、或分页机制拖了后腿。真正见效快的优化，集中在索引匹配、字段控制、链式位置、分页策略这四块。
排序字段必须有对应索引
order('created_at desc') 如果 created_at 没建索引，MySQL 就会触发 Using filesort，全表扫描+内存排序，数据量一过万，响应就明显卡顿。
- 等值查询 + 排序组合场景（如 where('status', 1)->order('created_at desc')），要建联合索引：
(status, created_at)，不能只建 status 或只建 created_at - 多条件排序（如 order(['sort' => 'asc', 'id' => 'desc'])），索引需覆盖全部字段且顺序一致：
(sort, id) - 范围条件（如 score > 80）放在联合索引靠后位置，它之后的字段无法被索引利用，所以
(status, score, created_at)中，created_at 在 score 后面就失效了 - 用
getLastSql()拿到真实 SQL，前面加EXPLAIN执行，确认 key 非 NULL、type 不是 ALL、Extra 里没有 Using filesort
order() 必须写在 select() 之前
链式调用中，order 的位置直接影响是否生效——写在 select() 或 find() 后面，会被忽略；模型 initialize() 里硬写的 $this->order() 还会强制覆盖外部所有 order，且无法清除。
- 正确写法：
User::where('status', 1)->order('id desc')->limit(10)->select() - 多字段排序推荐二维数组语法：
order([['sort', 'asc'], ['id', 'desc']])，避免键名冲突 - 含表达式排序（如中文拼音首字母）必须用
orderRaw("convert(name using gbk) asc")，普通 order() 不解析函数 - 关联查询时，order 字段要带表别名：
join('profile p', 'user.id=p.user_id')->order('p.sort desc')，否则报 Column 'sort' is ambiguous
字段越少，排序越快
select('*') 或不设 field()，会让 MySQL 加载大量冗余字段（尤其是 TEXT、JSON 类型），不仅传输慢，还可能触发磁盘临时表，拖累排序性能。
立即学习“PHP免费学习笔记（深入）”；
- 列表页只取必要字段：
field('id, title, status, created_at') - 字段含关键字（如 order、group）要用反引号：
field('`order`, status') - 关联预加载也要控字段：
with(['profile' => function($q) { $q->field('user_id, avatar'); }]) - 详情页和列表页字段分离，避免“一次查全、处处用不完”
大数据量排序别依赖 paginate
paginate(20) 查第 500 页时，MySQL 仍要跳过前 9980 行再取 20 条，count(*) + limit offset 成本极高，不是 TP 的问题，是 SQL 本身瓶颈。
- 改用游标分页（基于上一页最后一条的 created_at 或 id）：
where('created_at', 'order('created_at desc')->limit(20) - 排行榜类场景，禁止每次请求都 order('score desc')->limit(10)，应固化结果到缓存（如 Redis），定时或事件驱动更新
- 必须用分页时，关闭自动 count：
paginate(15, false, ['query' => request()->param()])，自己维护总数或用近似值 - 关联表外键字段要建索引，例如 orders(user_id, created_at)，否则 with() 里的 limit(3) 也挡不住全表扫描
