为何MySQL优先执行WHERE而非LEFT JOIN？效率低下问题求解

原因解析 #

1. LEFT JOIN被隐式转为INNER JOIN
   你添加的WHERE result = 'ERROR'会过滤掉所有result为NULL的行，而LEFT JOIN原本会保留SmallTable中没有匹配BigTable的记录（此时result为NULL），所以这条WHERE条件直接把LEFT JOIN变成了INNER JOIN，改变了查询的逻辑执行顺序。

2. 优化器执行计划选择的问题
   原LEFT JOIN的高效是因为MySQL先扫描小表SmallTable（2000条记录），再用这些记录的id去BigTable中匹配对应的SmallTableId，扫描范围极小。但添加WHERE条件后，优化器会评估：如果先过滤BigTable中result='ERROR'的行，再和SmallTable连接，在没有合适索引的情况下，需要全表扫描200万条BigTable数据，这就是耗时飙升的核心原因。

3. 子查询未生效的本质
   MySQL的查询优化器会对嵌套子查询做查询重写，自动将外层的WHERE条件推送到内层查询中，所以你写的子查询写法和直接加WHERE的执行计划完全一致，无法改变执行顺序，自然耗时相同。

解决方法 #

方法1：创建联合索引（最优解） #

给BigTable创建联合索引，让MySQL能快速定位到符合条件的行：

CREATE INDEX idx_smalltableid_result ON BigTable(SmallTableId, result);

这个索引同时覆盖连接条件和过滤条件，既能快速匹配SmallTable的id，又能直接过滤出result='ERROR'的记录，彻底避免全表扫描。

方法2：强制连接顺序 #

使用STRAIGHT_JOIN强制MySQL按照FROM子句的顺序执行连接，先扫描SmallTable，再用SmallTable的id去匹配BigTable的目标行：

SELECT * FROM SmallTable
STRAIGHT_JOIN BigTable 
ON BigTable.SmallTableId = SmallTable.id
WHERE BigTable.result = 'ERROR'

这种方式适合确认小表驱动大表更高效的场景，直接干预优化器的选择。

方法3：先过滤大表再连接 #

先在子查询中过滤BigTable的目标数据，再和SmallTable连接，明确执行顺序：

SELECT * FROM SmallTable
INNER JOIN (
    SELECT * FROM BigTable WHERE result = 'ERROR'
) AS filtered_big 
ON filtered_big.SmallTableId = SmallTable.id

这里用INNER JOIN替代原逻辑（因为WHERE条件已经过滤了NULL行），先得到BigTable中符合条件的子集，再和SmallTable连接，缩小关联范围。

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