ThinkPHP排序慢主因是MySQL未走索引导致Using filesort：ORDER BY字段未落在有效索引上、联合索引顺序与查询不匹配、字段类型不一致或使用函数均会导致索引失效，需结合EXPLAIN分析并按最左前缀原则设计索引。
ThinkPHP 排序慢，大概率不是框架本身的问题，而是生成的 SQL 被 MySQL 强制执行 Using filesort —— 这说明排序没走索引，MySQL 不得不把结果集捞出来再内存或磁盘里重排。
为什么 order() 一加就触发 Using filesort
关键看 ORDER BY 字段是否落在有效索引上，且满足最左前缀原则。ThinkPHP 的 order() 只负责拼 SQL，不帮你建索引。
- where 条件用了
user_id，但 order 是created_at，而你只给created_at单独建了索引 → 没用，key列为空，Extra出现Using filesort - 联合索引是
(status, user_id)，但你where('status', 1)->order('user_id desc')→ 可以用；换成where('user_id', 123)->order('status desc')→ 索引失效，照样Using filesort - 字段类型不一致：数据库里
user_id是VARCHAR，PHP 传的是整数123→ MySQL 隐式转换，索引失效，排序被迫回表再排 - 用了函数或表达式：
orderRaw('FIELD(id, 3,1,2)')或order('UPPER(name)')→ 索引直接作废
ThinkPHP 多字段排序写法影响索引命中
数组写法比字符串更安全，但更重要的是它决定了字段顺序是否对齐索引结构。
- 正确对齐索引：
->where('category_id', 5)->order(['category_id' => 'asc', 'sort_order' => 'asc'])，对应索引(category_id, sort_order) - 错误顺序：
->order(['sort_order' => 'asc', 'category_id' => 'asc'])→ 即使索引存在，也大概率无法利用 - 关联表字段排序（如
user.name）必须显式join()，with()预加载后在 PHP 层排序 → 数据量大时内存暴涨、速度断崖下跌 - 别用字符串拼接
order('user.name asc, created_at desc')：字段名没转义，遇上点号或关键字直接报错SQLSTATE[42S22]: Column not found
EXPLAIN 看不到 filesort 就等于优化成功？
不一定。即使 Extra 没写 Using filesort，也可能只是“侥幸”走了索引覆盖，实际性能仍差。
立即学习“PHP免费学习笔记（深入）”；
-
type是index（全索引扫描）而非range或ref→ 扫描行数爆炸，排序压力仍在 -
rows值远大于最终结果数 → 说明 MySQL 拿了大量无用数据去排序，I/O 和 CPU 都吃紧 - 复合条件 + 排序混用时，
WHERE中有范围查询（如created_at > '2024-01-01'），后面所有ORDER BY字段都无法利用联合索引的有序性 - 测试一定要用真实数据量：本地 100 条没问题，线上百万级一跑就卡死
真正卡点往往不在 order() 写法，而在 where 条件与索引设计是否形成闭环。一个 Using filesort 提示背后，通常是索引缺失、顺序错位、或类型不匹配三个问题中的至少一个。别急着改代码，先拿 getLastSql() + EXPLAIN 定位到具体哪条 SQL 在拖后腿。
