减少JOIN表数量能直接降低IO负载
数据库执行多表JOIN时，每增加一个表，就可能触发一次全表扫描或索引范围扫描。尤其当驱动表结果集较大、被驱动表又缺乏有效索引时，事情会变得棘手——MySQL或PostgreSQL很可能会把中间结果写入磁盘临时表（比如TempTable或work_mem溢出），大量随机IO就此产生。问题的核心往往不在于JOIN本身慢，而是“没经过充分过滤就匆忙JOIN”，导致需要读取和处理的数据量呈指数级膨胀。
为什么减少JOIN表数量能直接降低IO负载
简单来说，每增加一个JOIN表，就相当于在查询执行的流水线上多增加了一道工序和一份待处理的原材料。当驱动表的结果集很大，而被关联的表又缺少高效的索引路径时，数据库引擎就不得不进行全表扫描，或者将庞大的中间结果暂存到磁盘。这个过程会产生大量的随机IO操作，成为性能的主要瓶颈。所以，减少JOIN表的数量，本质上是简化了查询的复杂度，直接降低了数据搬运和处理的负担。
用WHERE提前过滤，比在ON里塞条件更有效
很多开发者习惯把过滤条件都堆在ON子句里，但对于LEFT JOIN这类操作，需要特别注意：WHERE子句中的条件（特别是非空判断）可能会在逻辑上把左连接变成等效的内连接。不过，这里想强调一个更关键的原则：过滤动作发生得越早，参与后续JOIN计算的数据量就越少。只要业务逻辑允许，应该优先把那些能大幅缩小结果集的条件放到WHERE子句中。
WHERE条件在JOIN操作之前生效，能直接减少驱动表需要扫描的行数。ON子句主要定义表之间的关联逻辑，它本身通常不会减少被驱动表的访问量（除非数据库优化器使用了索引下推等特性）。- 来看个例子：
SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE o.status = 'paid'。这里的WHERE条件让查询只扫描状态为“已支付”的订单，而不是全表订单，从而在源头就减少了数据量。
用子查询或CTE预聚合，避免大表直接JOIN
如果某个表参与JOIN仅仅是为了获取一些统计值（例如用户的最近一次订单时间、商品的月度销量总和），那么最好不要把整张表直接拉进来关联。更优的做法是，先用子查询或者公共表表达式（CTE）预先计算好聚合结果，生成一个精简的中间结果集，再去关联主表。这种方法不仅能显著减少IO，还能避免因直接JOIN大表而可能引发的重复计算和结果集放大的问题。
- 需要优化的写法：
SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id（这种写法容易产生用户表和订单表之间的笛卡尔积倾向，数据量巨大）。 - 改进后的写法：
SELECT u.name, last_order.amount FROM users u JOIN (SELECT user_id, MAX(amount) AS amount FROM orders GROUP BY user_id) last_order ON u.id = last_order.user_id。这里先通过子查询获取每个用户的最大订单金额，再用这个轻量的结果去关联用户表。 - 需要注意：用于预聚合的子查询本身必须有合理的索引支撑，否则
GROUP BY操作也可能导致全表扫描，功亏一篑。
警惕隐式类型转换导致索引失效
这是一个隐蔽却常见的性能杀手：当JOIN关联字段的数据类型不一致时（例如一张表的user_id是INT，而另一张关联表log的user_id是VARCHAR），数据库优化器可能会放弃使用索引，转而进行全表扫描。在这种情况下，即使只JOIN两张表，IO开销也可能急剧上升。
- 务必检查查询的执行计划，留意是否出现了
type: ALL（全表扫描）或Extra: Using join buffer（使用连接缓冲区）这类提示。 - 使用
SHOW CREATE TABLE命令仔细确认关联字段的数据类型、字符集和排序规则是否完全一致。 - 临时解决方案是进行显式类型转换，例如
ON u.id = CAST(l.user_id AS SIGNED)，但这通常会影响性能。最根本的办法是调整表结构，确保类型一致，一劳永逸。
最后，还有一个最容易被忽略的要点：SQL语句中写的JOIN顺序，并不一定是数据库优化器实际执行的顺序。优化器会根据统计信息重新排列连接顺序以寻求最优路径。因此，不能只关注SQL中写了几个表，更要通过EXPLAIN命令查看实际的执行计划：谁是驱动表？有没有用上预期的索引？估算的扫描行数（rows）是否合理？没有经过执行计划验证的所谓“减少表数量”，有时只是一种心理安慰。
