ORDER BY 变慢主因是未走索引触发 Using filesort 或临时表，关键在排序字段是否被驱动表或被驱动表的复合索引覆盖（如 INDEX(join_col, order_col)），且需避免隐式转换、函数操作及类型不一致。
排序字段没索引，ORDER BY 就会变慢
多表连接后加 ORDER BY，如果排序字段不在驱动表或被驱动表的索引覆盖范围内，MySQL 很可能走 Using filesort，甚至生成临时表。这不是“排序本身慢”，而是因为数据在连接后才排序，中间结果集太大、无序、无法利用索引。
关键判断点：看 EXPLAIN 的 Extra 列是否出现 Using filesort 或 Using temporary；再看 rows 是否远高于预期——说明排序前已扫描大量行。
- 优先给参与
ORDER BY的字段建索引，尤其是最终输出里最常用于排序的列（如created_at、score） - 如果排序字段来自被驱动表，且该表是大表，仅单列索引不够——需结合连接字段建复合索引，顺序为
(join_col, order_col)（例如INDEX(user_id, created_at)） - 避免在
ORDER BY中使用函数或表达式，比如ORDER BY UPPER(name)，这会让索引失效 - 若排序字段类型与索引字段不一致（如 VARCHAR 对比 INT 比较），可能触发隐式转换，同样跳过索引
三张及以上表 JOIN 时，ORDER BY 字段选在哪张表上很关键
MySQL 不会为整个连接结果建“联合索引”，它只能依赖某一张表的索引完成排序。所以必须明确：你希望排序逻辑落在哪张表上？这张表是否能成为驱动表？它的索引是否支持高效定位 + 排序？
常见错误是把 ORDER BY t3.updated_time 写在四表 JOIN 后，但 t3 是最后一个被关联的大表，既不是驱动表，其 updated_time 也未建索引——结果就是全量连接完再排序。
- 如果排序字段在小表（如状态字典表
status_map）上，且该表过滤后行数极少，可考虑用STRAIGHT_JOIN把它设为驱动表，再让排序走它的主键或二级索引 - 如果排序字段在大事实表（如
order_items）上，不要指望靠它驱动；应先用子查询或 CTE 提前按order_items.updated_time降序取 top N，再和其他表关联 - 对
LEFT JOIN右表的字段排序要格外小心——右表可能有 NULL，MySQL 无法用其索引做有序扫描，容易退化为 filesort
LIMIT + ORDER BY 在多表 JOIN 中容易翻车
LIMIT 10 看似简单，但在多表 JOIN 场景下，MySQL 必须先完成全部连接、排序，再截断。如果中间结果集有百万行，只为取前 10 条，代价极高。
典型症状：执行时间波动大、EXPLAIN 显示 rows 极高、Extra 出现 Using filesort 和 Using temporary 并存。
- 别写
SELECT * FROM a JOIN b ON ... ORDER BY x LIMIT 10，尤其当a或b是大表时 - 改用“分步法”：先从主表按排序字段 + 条件查出 ID 列表（带 LIMIT），再用这些 ID 关联其他表 —— 这样连接的数据量可控
- 如果主表排序字段区分度高（如时间戳+唯一ID），可用
WHERE created_at > ? ORDER BY created_at DESC LIMIT 10配合索引快速定位，再反向 JOIN - 注意
LIMIT在UNION或子查询中位置：它必须作用于最终结果集，不能只放在某一个子句里就以为能控制整体规模
ORDER BY 和 JOIN 条件字段类型不一致导致索引失效
这是线上最容易被忽略的隐形坑：两张表的关联字段类型看着一样，但一个是 VARCHAR(32)，另一个是 CHAR(32)；或者一个是 INT，另一个是 BIGINT；又或者字符集不同（utf8mb4 vs utf8）。MySQL 会静默做隐式转换，导致被驱动表的索引完全不生效，连带影响后续 ORDER BY 的可行性。
现象是：EXPLAIN 显示 type=ALL，key=NULL，哪怕你明明给那个字段建了索引。
- 用
SHOW CREATE TABLE table_name对比所有 JOIN 字段的完整定义：包括类型、长度、是否允许 NULL、字符集、排序规则 - 检查
ON条件两侧字段是否严格一致，尤其注意TINYINT和BOOLEAN（后者是别名）、TEXT和VARCHAR的隐式转换边界 - 如果必须跨类型关联（如老系统迁移），宁可用
CAST()显式转换，并确保转换后的字段上有函数索引（MySQL 8.0+）或冗余字段+索引 - 排序字段也适用同一原则：如果
ORDER BY t1.id，而t1.id是INT UNSIGNED，但你在 WHERE 中写了t1.id = ?传入的是有符号整数，也可能触发转换
实际优化时，最耗时间的往往不是写 SQL，而是确认每张表的 rows 估算是否靠谱、每个 ON 字段是否真走了索引、以及 ORDER BY 落在哪一层物理扫描上。这些细节不验证，光调顺序或加索引，大概率白忙。
