MySQL 5.7中ORDER BY触发Using filesort主因是索引未被有效复用，需通过EXPLAIN查Extra字段、SHOW PROCESSLIST看Sorting result状态，并建满足最左前缀且无函数/混合方向的联合索引（如status, category, created_at）来消除。
MySQL 5.7 中 ORDER BY 触发 Using filesort，绝大多数情况不是排序慢，而是根本没走索引排序——CPU 飙升、查询变卡，根源是 MySQL 被迫反复做内存/磁盘排序 + 回表 + 归并，而不是“数据太多排不过来”。
怎么确认是不是真被 Using filesort 拖垮了？
别猜，直接看执行计划和运行时状态：
- 执行
EXPLAIN SELECT ... ORDER BY ...，紧盯Extra字段：出现Using filesort就坐实了 - 同时检查
key字段：如果是NULL，说明连索引都没用上；如果用了索引但仍有Using filesort，说明索引结构不匹配排序需求 - 运行中查
SHOW PROCESSLIST，看是否有大量连接卡在Sorting result或Creating sort index状态 - 用性能视图定位罪魁：
SELECT DIGEST_TEXT, SUM_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%ORDER BY%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 3
为什么明明建了索引，ORDER BY 还是不走？
索引存在 ≠ 排序可用。5.7 对索引复用极其苛刻，常见失效场景包括：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
WHERE a > 10 ORDER BY b：范围条件后跟排序列，除非索引是(a, b)且b是第二列，否则大概率退化 -
ORDER BY UPPER(name)或ORDER BY created_at + INTERVAL 1 DAY：任何函数/表达式都会绕过索引有序性 -
ORDER BY a ASC, b DESC：MySQL 5.7 不支持混合方向，必须全 ASC 或全 DESC 才能复用联合索引 -
WHERE status = ? AND category IN (?, ?) ORDER BY created_at：IN是范围语义，会截断索引使用链，created_at很可能无法参与排序 - 字符集或
collation不一致：比如索引建在VARCHAR(255) COLLATE utf8mb4_0900_as_cs，而查询里隐式转成utf8mb4_general_ci，索引直接被忽略
建什么索引才能真正消除 Using filesort？
目标很明确：让 EXPLAIN 的 Extra 字段为空，且 key 显示命中索引。关键动作是构造「查询友好型」联合索引：
- 把
WHERE中的等值条件列放最左，排序列放最后：例如常用WHERE status = ? AND category = ? ORDER BY created_at DESC，就建INDEX idx_status_category_created (status, category, created_at) - 避免在排序字段上做任何计算：如需格式化时间，放到应用层处理；若必须保留，可加虚拟生成列（MySQL 5.7 支持）再建索引，但要注意补丁版本是否启用该功能
- 如果
SELECT只要少数字段，考虑覆盖索引：比如SELECT id, title FROM posts WHERE status = 1 ORDER BY created_at DESC，可建INDEX (status, created_at, id, title)，彻底避免回表 - 慎用
ORDER BY NULL：它只对显式写了ORDER BY但又不需要顺序的场景有效（如聚合后分页），不能修复索引缺失问题
sort_buffer_size 和 max_length_for_sort_data 调多少才合适？
参数调优是补救手段，不是替代索引的方案。但配错会放大问题：
-
sort_buffer_size默认 256KB，太小会导致频繁写临时文件；可按并发连接数 × 单次排序量估算，单线程建议不超过 4MB，避免内存浪费 -
max_length_for_sort_data控制排序模式：值越大越倾向「全字段排序」（减少回表 IO），但会吃更多sort_buffer；若查询字段总长常超 1024 字节，默认就会切到<sort_key rowid></sort_key>模式，引发随机 IO —— 此时加大该值比盲目加sort_buffer_size更有效 - 注意：这些参数是 per-connection 的，全局设太高会撑爆内存；优先确保索引正确，再微调
最易被忽略的一点：即使 EXPLAIN 显示走了索引、没 Using filesort，如果 innodb_buffer_pool_size 远小于数据量，MySQL 仍要反复读盘加载索引页和数据页，排序延迟会藏在 I/O 里，看起来像“索引生效但还是慢”。先看缓冲池命中率，再调参。
