应优先创建联合索引满足GROUP BY和ORDER BY需求，如ALTER TABLE orders ADD INDEX idx_status_user_time(status, user_id, created_at)，使查询通过索引避免临时表和文件排序，提升执行效率。
在MySQL中优化包含 ORDER BY 和 GROUP BY 的混合查询，关键在于合理使用索引减少排序和分组的开销。这类查询容易引发临时表和文件排序（Using filesort），导致性能下降。通过正确的索引设计，可以显著提升执行效率。
理解执行顺序与索引匹配原则
MySQL通常先执行 GROUP BY，再处理 ORDER BY。如果 GROUP BY 和 ORDER BY 涉及相同或部分重叠的列，索引需要同时满足两者的需求。理想情况是建立一个联合索引，覆盖 GROUP BY 和 ORDER BY 所需字段。
索引生效的前提是遵循最左前缀原则，并且字段顺序要匹配查询中的使用顺序。
创建合适的联合索引
假设有一张订单表：
CREATE TABLE orders (id INT PRIMARY KEY,
user_id INT,
status TINYINT,
amount DECIMAL(10,2),
created_at DATETIME
);
执行如下混合查询：
SELECT user_id, SUM(amount)FROM orders
WHERE status = 1
GROUP BY user_id
ORDER BY created_at DESC;
这个查询无法直接用一个索引同时满足 GROUP BY 和 ORDER BY，因为 created_at 不在 GROUP BY 中，且不在索引末尾。应优先优化 GROUP BY，然后考虑是否能避免排序。
更合理的做法是调整业务逻辑或改写查询。例如，若想按用户最近下单时间排序，可改写为：
SELECT user_id, SUM(amount), MAX(created_at) as last_orderFROM orders
WHERE status = 1
GROUP BY user_id
ORDER BY last_order DESC;
此时可创建索引：
ALTER TABLE orders ADD INDEX idx_status_user_time (status, user_id, created_at);
该索引作用：
- status 用于 WHERE 过滤
- user_id 支持 GROUP BY 分组
- created_at 覆盖 MAX() 计算并支持 ORDER BY
避免临时表和文件排序
通过 EXPLAIN 检查执行计划，重点关注：
- type：尽量避免 ALL 扫描
- key：确认使用了预期索引
- Extra：避免出现 Using temporary 和 Using filesort
若 Extra 中仍有 Using filesort，说明排序未走索引。可通过以下方式缓解：
- 缩小 WHERE 条件范围，减少参与分组的数据量
- 限制返回行数（加 LIMIT）
- 将 ORDER BY 字段加入 GROUP BY（如语义允许）
特殊情况处理
当 GROUP BY 和 ORDER BY 字段完全不同且无法共用索引时，可考虑：
- 拆分查询：先 GROUP BY 得到结果集，再关联原表获取排序字段
- 使用覆盖索引减少回表次数
- 对高频查询建立物化视图或汇总表
例如：
SELECT o1.user_id, o1.totalFROM (
SELECT user_id, SUM(amount) total
FROM orders WHERE status = 1 GROUP BY user_id
) o1
JOIN orders o2 ON o2.user_id = o1.user_id
ORDER BY o2.created_at DESC LIMIT 10;
此时可在 (user_id, created_at) 上建索引辅助 JOIN 排序。
基本上就这些。关键是根据实际查询模式设计索引，优先保证 GROUP BY 高效，再尽可能消除排序开销。不复杂但容易忽略细节。
