为何在SQL中先过滤数据再执行JOIN能大幅减少IO开销？

过滤应放在WHERE而非ON子句，尤其LEFT JOIN中ON后加单表条件无法下推；显式子查询提前剪枝最可靠；JOIN字段类型必须一致且有合适索引；避免SELECT *，用覆盖索引减少IO。

因为过滤能直接砍掉参与JOIN的原始数据量，而IO开销主要来自“读多少行”——不是JOIN逻辑本身慢，是没过滤就JOIN导致数据库被迫扫描、传输、临时写入海量中间行。

WHERE条件放错位置，IO可能翻十倍

很多人把过滤条件全塞进ON子句，尤其在LEFT JOIN里写ON ... AND status = 'active'，这看似“提前过滤”，实则让优化器无法下推该条件到左表扫描阶段。结果是：左表全扫一遍，再连右表，最后才丢掉不匹配的行。

• WHERE作用于JOIN之后的结果集，但对单表条件（如users.status = 'active'），优化器通常能下推到该表扫描时执行——真正减少磁盘读
• ON只定义关联关系，不减少被驱动表的访问量，除非有索引下推（比如MySQL 8.0+对IN或等值条件的部分优化）
• 典型反例：SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id AND u.deleted = 0 → users仍被全表扫描；改成WHERE u.deleted = 0会失效左连接，正确做法是LEFT JOIN (SELECT * FROM users WHERE deleted = 0) u ON ...

用子查询或CTE显式提前剪枝

依赖优化器自动下推不可靠，尤其遇到OR、LIKE '%xx'、DATE(created_at)这类函数包裹字段时，下推大概率失败。显式子查询是最稳的控制方式。

• 慢写法：SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'shipped' AND o.created_at > '2025-01-01' → 执行计划常显示rows_examined达百万级
• 快写法：SELECT u.name, o.amount FROM users u JOIN (SELECT user_id, amount FROM orders WHERE status = 'shipped' AND created_at > '2025-01-01') o ON u.id = o.user_id → orders扫描行数从10万降到几百
• 注意：子查询里必须有支撑索引，比如(status, created_at, user_id, amount)，否则GROUP BY或WHERE本身又成全表扫

JOIN字段类型不一致，索引直接失效

哪怕只JOIN两张表，只要关联字段类型不匹配（比如user_id INT vs log.user_id VARCHAR），数据库就会放弃走索引，转为全表扫描——这时“先过滤”也救不了IO爆炸。

• 隐式转换常见于日志表、宽表导出、跨系统同步场景，查EXPLAIN时注意type是否为ALL或index，Extra是否含Using where但无Using index
• 修复方法不是加索引，而是统一字段类型：ALTER TABLE log MODIFY user_id INT UNSIGNED，再补索引
• 复合索引顺序错误也会导致失效，例如想按status和user_id过滤，却建了(user_id, status) —— WHERE status = 'paid'无法用上该索引

SELECT * 或冗余字段会放大IO问题

每多选一个字段，尤其是TEXT、JSON、BLOB或宽字段（如50列的用户表），数据库就得从磁盘多读一页或多页，网络多传一次，内存多存一份——这些开销在JOIN后会被乘以关联行数。

• 坏习惯：SELECT * FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active' → 即使只要u.id和o.amount，也得把整行users和orders都捞出来
• 覆盖索引可缓解：建INDEX idx_user_active (status, id, name, email)，让WHERE status = 'active' + SELECT id, name全程走索引，不回表
• ORM用户特别注意：Django默认.all()生成SELECT *，要用.values('id', 'name')或.only('id', 'name')显式约束

最常被忽略的点是：你以为的“小表驱动大表”，其实驱动表根本没索引，或者JOIN字段类型不一致——这时候无论怎么调WHERE位置、写多漂亮的子查询，IO都降不下来。先看EXPLAIN里的key和rows，再动手改SQL。