JOIN前先过滤可显著降低网络传输量，避免大表全量加载；应确保WHERE条件在JOIN前执行，用覆盖索引减少回表，预聚合临时表避免重复传输，并优先优化网络拓扑而非盲目加索引。
JOIN前先过滤，别让大表拖着走
网络延迟高时，传输数据量直接决定耗时。SQL执行计划里如果JOIN发生在WHERE过滤之前，数据库可能把整张大表（比如千万级orders）全拉到内存里再关联，光是网络传输就卡死。
常见错误现象：执行时间忽高忽低，监控显示Bytes sent to client暴涨，但CPU和磁盘IO并不高。
- 用
EXPLAIN确认JOIN顺序，优先让带强索引条件的表做驱动表 - 把能下推的过滤条件全写进
ON或子查询里，比如LEFT JOIN (SELECT * FROM logs WHERE created_at > '2024-01-01') l ON ... - 避免在
JOIN后用WHERE筛驱动表字段——这会让优化器放弃提前裁剪
用覆盖索引避免回表+跨网传输
高延迟下，一次SELECT *带来的多轮往返比单次大包更伤。尤其当JOIN涉及二级索引字段时，MySQL/PostgreSQL常要回主键再查数据，每次回表都是一次网络抖动。
使用场景：报表类查询只取几个字段，但关联了用户、订单、地址三张表。
- 在关联字段和查询字段上建联合索引，例如
CREATE INDEX idx_user_id_status ON orders(user_id, status, amount) - 显式列出需要的字段，禁用
SELECT *；连id都别多选，除非真要用 - PostgreSQL注意
INCLUDE子句，MySQL 8.0+留意COVERING INDEX是否生效（Extra列含Using index）
临时表预聚合，砍掉重复JOIN
如果同一张大表被多个JOIN反复引用（比如users被关联三次），每次都在网络上传一遍，延迟直接乘以三。
常见错误现象：慢查询日志里出现多个相似执行计划，rows_examined一致但rows_sent翻倍。
- 用
WITHCTE或CREATE TEMPORARY TABLE把中间结果固化，例如WITH recent_users AS (SELECT id, name FROM users WHERE last_login > NOW() - INTERVAL 7 DAY) - 确保临时表有合适索引（MySQL临时表默认无索引，需显式
CREATE INDEX） - 注意连接池超时：临时表生命周期绑定会话，长事务可能撑爆内存
别信“加索引万能”，先看JOIN方向和网络拓扑
有些团队一遇到慢JOIN就加索引，结果发现延迟没变——因为瓶颈根本不在数据库计算，而在应用服务器和数据库之间的物理距离。
性能影响：跨机房（如上海应用连北京DB）RTT 40ms，一个JOIN若触发两次网络往返，光握手就吃掉80ms，索引再快也补不回。
- 用
tcpdump或pt-query-digest --watch-server确认实际网络耗时占比 - 如果应用和DB不在同可用区，优先考虑读写分离+就近路由，而不是调优SQL
- MySQL的
join_buffer_size调太大反而会增加单次传输压力，建议保持默认值（256K–2M），靠逻辑拆分减数据量
复杂点在于：延迟不是恒定值，它随包大小非线性增长。一个2MB的结果集，在40ms RTT链路上可能花300ms，但拆成两个1MB请求可能只要400ms——看似多一次往返，实际更快。这点容易被EXPLAIN忽略。
