先判断：慢在扫描，还是慢在返回结果
JOIN 查询出现高延迟时，不要先凭经验把 join_buffer_size 调大，也不要只看两张表的总行数。优化器真正关心的是过滤条件执行后还剩多少行，以及关联列能否快速定位匹配记录。
例如订单表有数千万行，但按时间和状态过滤后只剩几百行，那么它可能比一张总量较小、却几乎没有过滤条件的表更适合作为连接的起点。判断 JOIN 是否需要优化，建议先记录实际 SQL、参数和返回行数，再查看执行计划：
EXPLAIN ANALYZE
SELECT o.order_id, u.username
FROM orders AS o
JOIN users AS u ON u.id = o.user_id
WHERE o.create_time >= '2026-09-01'
AND u.status = 'ACTIVE';重点关注以下信息：
key是否使用了预期索引，还是显示为NULL；rows与实际扫描行数是否明显偏大；possible_keys中的索引是否因为选择性、类型转换或表达式而没有被采用；Extra是否出现全表扫描、临时表、排序或连接缓冲相关提示；- 估算行数和实际行数差距是否很大。
EXPLAIN 适合快速了解优化器的计划，EXPLAIN ANALYZE 则能把实际执行时间和实际行数带进分析。线上排查时要使用脱敏后的真实参数，并避免直接在高峰期反复运行大查询。
驱动表不是“总行数更小的表”
在常见的嵌套循环连接中，驱动表产生一批候选行，另一张表再根据关联条件寻找匹配项。因而，“小表驱动大表”只能作为粗略经验，不能替代执行计划。更可靠的判断方式是比较过滤后的结果集，以及被驱动表能否通过索引完成定位。
对于 INNER JOIN，优化器可以根据统计信息和谓词条件调整连接顺序；对于 LEFT JOIN，外连接的语义通常要求保留左表行，因此左表顺序受到更多限制。如果 WHERE 条件又排除了右表为空的情况，查询在语义上可能退化为内连接，优化器才有机会采用更灵活的顺序。不要仅凭 SQL 的书写顺序猜测最终执行计划。
下面这类索引通常比调整连接参数更值得优先检查：
CREATE INDEX idx_orders_user_time
ON orders (user_id, create_time);
CREATE INDEX idx_users_status_id
ON users (status, id);具体列顺序要结合过滤条件、连接条件和选择性测试。索引并不是列越多越好：过宽的联合索引会增加写入成本、占用空间，也可能因最左匹配规则不符合查询而无法充分利用。
被驱动表没有关联索引，会发生什么
假设外层先得到 1000 个订单用户编号，而 users.id 没有可用索引。数据库可能需要为多个外层行反复扫描用户表，扫描成本会随着外层结果集增长。若关联列存在合适索引，连接可以针对每个外层值快速定位匹配记录，通常比重复全表扫描更稳定。
这里的“有索引”还不够准确，至少要核对四件事：
- 索引是否建在真正参与连接的列上；
- 两侧数据类型、字符集和排序规则是否兼容，避免隐式转换让索引失效；
- 关联列是否被函数、计算或不必要的类型转换包裹；
- 过滤条件与连接条件组合后，索引顺序是否仍然适合该查询。
如果关联列的基数很低，或者过滤后大部分行都会被访问，优化器不使用索引也可能是合理选择。此时应通过执行计划和实际耗时验证，而不是强行使用索引提示。
Join Buffer 与 Hash Join：不要把两个概念混为一谈
在较早版本的 MySQL 中，无索引连接可能使用 Block Nested-Loop，并借助 Join Buffer 暂存一批外层行，减少重复扫描次数。MySQL 8.0.18 引入了 Hash Join，8.0.20 起 Block Nested-Loop 相关实现发生变化；在较新的 8.0 版本中，执行计划可能显示 Using join buffer (hash join)。
Hash Join 的思路不同：优化器选择一侧结果集构建哈希结构，另一侧逐行探测。join_buffer_size 会影响连接操作可使用的内存，但它不是“越大越快”的开关，也不能替代关联索引。
调参数前先确认：
- 执行计划是否确实采用了 Hash Join 或连接缓冲；
- 构建侧结果集是否过大，是否出现内存不足或溢出相关现象；
- 查询是否只是因为
SELECT *携带了过多列； - 并发连接数上升后，单连接内存叠加是否会带来压力。
join_buffer_size 通常按连接分配，盲目提高全局值会放大并发场景下的内存风险。线上调整前应在接近真实数据量和并发量的环境中压测，并观察延迟、吞吐、内存和临时文件，而不是只看单次查询时间。
一套可执行的 JOIN 排查顺序
可以按下面的顺序处理大多数 JOIN 变慢问题：
- 固定复现条件：记录 SQL、参数、返回行数和数据分布，区分偶发慢查询与稳定性问题。
- 查看执行计划：先用
EXPLAIN，再用EXPLAIN ANALYZE对照估算行数和实际行数。 - 检查过滤条件：让高选择性的过滤尽可能在连接前生效，但不要为了“提前过滤”而写出改变语义的 SQL。
- 核对关联列索引：确认被访问表的连接列可用，并排查类型不一致、函数包裹和隐式转换。
- 减少无效数据搬运：明确列名，避免
SELECT *；删除不必要的排序、去重和多余连接。 - 刷新统计信息并复测：数据分布变化后，旧统计信息可能导致连接顺序判断失真。
- 最后再看参数：只有确认算法、数据量和内存边界后，才考虑调整连接缓冲相关参数。
结语
MySQL JOIN 优化的核心不是背诵“哪张表更小”，而是用执行计划确认过滤后的结果集、连接顺序和访问路径。多数问题应先从关联列索引、数据类型、过滤条件和返回列入手；Hash Join 或 Join Buffer 参数只适合在明确的执行计划和压测结果支持下调整。
对个人站长、小团队和业务开发者来说，最实用的做法是把慢查询样本、执行计划和数据规模一起保存下来，形成可回归的优化记录。这样每次加索引、改 SQL 或升级 MySQL 后，都能判断性能变化来自哪里，而不是依赖一次偶然的测试结果。