先说结论：在SQL查询中，先Filter再Join确实更快，因为中间结果集一旦缩小，JOIN的计算量就会断崖式下降。但如果WHERE条件里含有OR、LIKE或者函数调用这类“不可下推”的表达式，那优化器大概率不会帮你提前过滤。这时候，就得靠子查询或CTE来手动控制过滤时机了。
关键在于中间结果集的大小，它直接决定了JOIN的运算量。想象一下：同样是JOIN，左边是100万行扫全表，和左边只有几百条过滤后的有效数据，哪种更快？答案不言自明。先Filter一下，把百万级的数据压到几百行，JOIN的开销自然也跟着断崖式下降。
WHERE写在JOIN后 vs 写在子查询里，执行计划差异巨大
数据库的执行顺序是 FROM → ON → JOIN → WHERE，但优化器是否真的能把WHERE下推到JOIN之前，这取决于表达式本身。碰到OR、LIKE '%abc'、DATE(created_at)这类玩意儿，MySQL 8.0以上和PostgreSQL很大程度上会选择放弃下推。结果就是：先让两张表全量JOIN完，再回头做过滤，那当然慢了。
- 想预测执行计划？查
rows字段最直观。如果orders表上显示扫描了200万行，但实际满足status = 'PAID'的只有8000行，那就说明过滤没有提前生效。 - 用子查询显式控制驱动表行数是个好办法。比如把
(SELECT * FROM orders WHERE status = 'PAID')作为右表，驱动行数就能从10万降到8000。 - CTE在PostgreSQL里可读性更强，MySQL 8.0以上也支持，语义等价——相比裸写
WHERE，它们都更可靠。
LEFT JOIN里把右表条件放WHERE里，等于悄悄转成INNER JOIN
这里有个容易掉进去的坑：ON决定“怎么连”，WHERE决定“连完留哪些”。一旦你把右表字段的条件写在WHERE里，数据库会把左表没匹配上的行全踢掉——语义就变了，性能也跟着崩了。
- 错误示例：
LEFT JOIN orders o ON u.id = o.user_id WHERE o.created_at > '2025-01-01'→ 那些没有订单的用户直接消失，LEFT JOIN等于白写。 - 正确做法：
LEFT JOIN (SELECT * FROM orders WHERE created_at > '2025-01-01') o ON u.id = o.user_id→ 用户全量保留，orders表也只扫描1/10的行。 - 如果非得在
WHERE里干这事，可以改成WHERE o.created_at > '2025-01-01' OR o.created_at IS NULL，但这逻辑复杂了，索引效果也不好。
聚合查询不先GROUP BY再JOIN，就是在喂数据库吃内存
订单+用户+商品三张表直接JOIN完再COUNT()，中间结果可能是千万级的。反过来，先按user_id聚合订单，再JOIN用户信息，那JOIN对象就只是几百行的汇总表了。
- 慢写法：
SELECT u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id→orders全量参与JOIN。 - 快写法：
SELECT u.name, t.cnt FROM users u LEFT JOIN (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id) t ON u.id = t.user_id - 注意：子查询里的
GROUP BY必须包含JOIN键（如user_id），否则关联就失效了。
话说回来，很多开发者容易忽略一点：即使用了子查询，如果orders表上根本没有status或created_at的索引，那子查询自己也不过是全表扫描——Filter再早，没索引也是白搭。
