thinkphp排序性能下降的核心原因是排序字段未被索引覆盖、查询结构无法利用索引或大数据量触发using filesort；优化关键在于让数据库完成有序输出，而非php层二次排序。
ThinkPHP排序性能下降，核心原因往往不是order()本身，而是排序字段未被索引覆盖、查询结构导致无法利用索引，或数据量大时触发Using filesort。真正有效的优化，是让数据库在磁盘或内存中完成有序输出，而非PHP层二次排序。
确保排序字段落在复合索引最右端
MySQL的B+树索引天然有序，但仅当查询条件与排序字段共同构成“最左匹配”时，才能避免额外排序。单列索引对WHERE + ORDER BY组合基本无效。
- 典型低效场景：
where('status', 1)->order('created_at desc')，若只有status或只有created_at索引，执行计划中会出现Using filesort - 正确做法：建立联合索引
(status, created_at)——等值条件放前，排序字段紧随其后 - 含范围条件时（如
score > 80），必须把范围字段放在索引末尾，否则其后的字段无法被索引利用；例如where('category_id', 5)->where('score', '>', 70)->order('sort')，应建索引(category_id, score, sort)
避免在order中使用函数或表达式
任何对字段的运行时计算都会使索引失效，强制全表扫描后再排序。
- ❌ 错误写法：
orderRaw('UPPER(name)')、orderRaw('DATE(create_time)')、orderRaw('id * 2') - ✅ 替代方案：
• 若需按日期归类，改用范围查询：whereBetween('create_time', ['2026-01-01', '2026-07-01'])，再按原字段排序
• 若需大小写不敏感排序，建生成列索引（MySQL 5.7+）：ALTER TABLE user ADD COLUMN name_lower VARCHAR(50) STORED AS (LOWER(name)); CREATE INDEX idx_name_lower ON user(name_lower);，然后order('name_lower')
大数据量下慎用paginate()，改用游标分页
传统LIMIT offset, size在深分页时性能断崖式下跌，因为数据库仍要扫描跳过的所有行。
- ❌ 避免：
paginate(20, false, ['page' => 1000])—— 实际执行LIMIT 19980, 20，扫描近2万行 - ✅ 推荐游标分页：
• 前端传上一页最后一条记录的id或created_at（必须是索引字段）
• 查询改为：where('id', 'order('id desc')->limit(20)
• 索引(id)即可高效定位，无需偏移计算
精简字段 + 启用查询缓存，降低排序开销
排序不仅消耗CPU，还显著增加I/O和内存压力——尤其当SELECT * 包含TEXT/BLOB字段时，临时表可能落到磁盘，性能骤降。
- 显式指定排序所需字段：
field('id, title, status, created_at')->order('created_at desc')，避免加载冗余大字段 - 对变动不频繁的排序结果启用缓存：
cache('article_list_new', 300)->order('created_at desc')->select()，5分钟内直接返回序列化结果，跳过SQL执行与排序 - 确认
config/database.php中'fields_cache' => true已开启，减少元数据查询开销
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
