MySQL 5.6优化器未尽早使用ORDER BY，查询性能问题求助

首先得拆解下你的问题根源：MySQL优化器基于成本估算，选择了先全表扫描order_info再关联order_shipping_info的路径，但这导致了百万级行扫描和低效的filesort。你想要的「先按order_date排序再关联」逻辑，MySQL默认没选，但咱们可以通过调整查询结构、优化索引来引导它，甚至变相实现这个逻辑。

核心解决方案 #

1. 用「预筛选小范围订单」的子查询实现先排序再关联 #

这个思路是先从order_info里快速取出最近的一批订单（比如1000条，远小于150万），再关联order_shipping_info筛选仓库5的订单，最后取前100条。子查询会直接用到order_date的索引，速度极快，后续关联也只处理少量数据：

SELECT oi.*
FROM (
    -- 先取最新的1000条订单，LIMIT值可根据仓库5的订单频率调整
    SELECT *
    FROM order_info
    ORDER BY order_date DESC
    LIMIT 1000
) oi
INNER JOIN order_shipping_info osi 
    ON oi.id = osi.order_info_id
WHERE osi.warehouse_id = 5
LIMIT 100;

只要仓库5的订单不是特别冷门，最新的1000条里肯定能凑够100条，这个查询耗时应该能降到几十毫秒级别。

2. 优化索引引导优化器自动选优 #

如果子查询方案不够稳妥，咱们可以通过添加复合索引让优化器主动选择高效路径：

• 给order_shipping_info创建索引：(warehouse_id, order_info_id)。这个索引能让MySQL快速定位仓库5的所有订单ID，无需扫全表。
• 给order_info创建索引：(order_date, id)。这个索引能让MySQL直接按order_date倒序取数，同时因为包含主键id，关联时不需要回表查额外数据。

添加索引后，你的原查询可能会自动优化；如果还是不行，可以用STRAIGHT_JOIN强制连接顺序（先查order_shipping_info拿仓库5的订单ID，再关联order_info排序）：

SELECT oi.*
FROM order_shipping_info osi
STRAIGHT_JOIN order_info oi 
    ON osi.order_info_id = oi.id
WHERE osi.warehouse_id = 5
ORDER BY oi.order_date DESC
LIMIT 100;

关于「强制先ORDER BY再关联」的说明 #

在MySQL 5.6里，没有直接语法能强制优化器先执行ORDER BY再关联——优化器是基于成本估算选执行计划的。但咱们可以通过上面的子查询方式变相实现这个逻辑：先在子查询里完成排序和小范围筛选，再和配送表关联，本质上就是先排序再过滤关联。

你可以用EXPLAIN查看执行计划，确认索引是否生效：比如子查询的type是否为index（用到了order_date索引），关联时的type是否为eq_ref（用到了主键索引）。

内容的提问来源于stack exchange，提问作者Jessie