thinkphp查询排序慢的根源是order by字段未建索引导致filesort；需按where等值字段、范围字段、order by字段顺序创建联合索引，并通过fetchsql、explain和压测三步验证索引有效性。
ThinkPHP 查询排序慢，不是模型写得不好，而是数据库没给排序字段建索引——Filesort 一出现，基本就坐实了这点。
为什么 order by 字段没索引就会触发 Filesort
MySQL 执行 ORDER BY 时，如果排序字段没有可用索引（或索引不匹配查询条件），就必须把结果集捞出来再内存/磁盘排序，这个过程叫 Filesort。它不读文件，但开销大、不可控、易拖垮分页接口。
- 常见现象：EXPLAIN 看到
Extra列显示Using filesort；接口响应从几十毫秒涨到数秒；并发稍高就 CPU 爆表 - ThinkPHP 场景下特别容易中招：比如用
order('created_at desc')查列表，但created_at没单独建索引，也没在联合索引最左前缀位置 - 注意：即使
WHERE用了索引，ORDER BY字段仍需独立满足索引覆盖条件；联合索引(status, created_at)对WHERE status = 1 ORDER BY created_at有效，但对WHERE user_id = 123 ORDER BY created_at无效
哪些排序字段必须加索引（ThinkPHP 典型场景）
别猜，按实际链式调用反推 SQL 的 ORDER BY 子句，再看字段是否高频、是否筛选性弱、是否常和 WHERE 组合使用。
-
created_at/updated_at：列表页默认排序字段，几乎必加单列索引；若常配合status使用（如「待处理订单」按更新时间倒序），建联合索引(status, updated_at)更优 -
sort/weight/score：运营后台手动置顶、权重排序字段，单独建索引；注意避免NULL值过多导致索引选择率下降 -
title/name：前台搜索+排序混合场景（如「按商品名排序」），建议建前缀索引（如title(50)），防长文本拖慢索引体积 - 禁止加索引的字段：如
content（全文检索走FULLTEXT）、password_hash（根本不该参与排序）、json类型字段（MySQL 5.7+ 可建函数索引，但 ThinkPHP 不直接支持表达式索引写法）
ThinkPHP 中验证索引是否生效的三步检查法
别只信文档或印象，每个排序接口都要实测。
- 第一步：用
->fetchSql(true)或开启db_debug，确认最终生成的 SQL 确实含ORDER BY xxx，且字段名与数据库列名完全一致（大小写、下划线都不能错） - 第二步：在 MySQL 中执行
EXPLAIN SELECT ... ORDER BY xxx，重点盯key（是否命中索引）和Extra（是否还有Using filesort） - 第三步：真实压测——用
ab或hey模拟 50 并发查第 100 页，观察慢日志是否还报该 SQL；有则说明索引未覆盖或统计信息过期（可ANALYZE TABLE更新）
联合索引顺序错了，比没索引还危险
ThinkPHP 的 where()->order() 链式调用，会拼出 WHERE a = ? AND b > ? ORDER BY c 这类混合语句。这时候联合索引字段顺序直接决定能否消除 Filesort。
- 错误示例：建了
(c, a, b)，但查询是WHERE a = 1 AND b > 10 ORDER BY c→ 索引只能用上c，a和b失效，且ORDER BY c因不在最左，仍触发Filesort - 正确顺序口诀：「WHERE 等值字段排最左，范围字段紧跟后，ORDER BY 字段放最后」。上例应建
(a, b, c) - 特殊情况：如果只有
ORDER BY没WHERE（如后台全量导出排序），那单列索引比联合索引更合适，避免冗余
最常被忽略的一点：索引不是建完就一劳永逸。当业务加了新排序维度（比如突然要支持按「销量」排序），或者原有字段类型变了（VARCHAR(255) 改成 TEXT），旧索引可能直接失效。每次迭代上线前，扫一遍控制器里的 order() 调用点，同步核对索引定义。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
