真正让CPU瞬间拉满的是没索引的JOIN触发全表扫描与BNL机制反复加载数据，导致CPU疯狂匹配、IO频繁刷盘；优先加索引而非调join_buffer_size，95%以上问题根子在被驱动表ON字段缺失索引。
别急着调 join_buffer_size，它不是CPU爆表的解药，而是掩盖问题的创可贴。真正让CPU瞬间拉满的，是没索引的JOIN触发全表扫描+Block Nested-Loop（BNL）机制反复加载数据进内存，导致CPU疯狂做匹配计算、IO频繁刷盘。调大这个参数，只会让单次循环载入更多行，把CPU和内存一起拖垮。
先确认是不是真在用join buffer
执行 EXPLAIN FORMAT=TREE 或 EXPLAIN 查看执行计划：
- 如果
Extra列出现 Using join buffer (Block Nested Loop)，说明MySQL正在用BNL，且被驱动表没走索引 - 如果显示
type: ALL或type: index且key为空，基本坐实了全表扫描 - MySQL 8.0.22+ 默认禁用BNL、改用Hash Join，此时
join_buffer_size完全不生效——调它纯属白忙
优先加索引，而不是调参数
95%以上的JOIN CPU飙升，根子在索引缺失。重点检查被驱动表的ON条件字段：
- 例如
SELECT * FROM orders o JOIN users u ON o.user_id = u.id，必须确保users.id是主键或有索引，同时orders.user_id也建议建索引 - 复合查询中多个JOIN，逐个验证每张被驱动表是否有对应字段的索引，别漏掉中间表
- 用
SHOW INDEX FROM table_name确认索引实际存在，注意索引是否因数据类型隐式转换而失效
临时应急但不推荐长期依赖的操作
若线上无法立刻加索引，且必须跑这条SQL，可会话级微调作临时缓解（仅限调试，严禁写进配置文件）：
- 执行
SET SESSION join_buffer_size = 2097152;（即2MB），避免默认256KB导致过度分批扫描 - 配合
STRAIGHT_JOIN强制小表驱动，例如SELECT STRAIGHT_JOIN ... FROM small_table s JOIN big_table b ON ... - 观察
SHOW STATUS LIKE 'Select_full_join';是否下降，以及Rows_examined是否明显减少
彻底规避：换思路，别硬扛
当表实在太大（如日志类千万级表）、又无法加索引时，放弃单条JOIN：
- 按主键范围分批查驱动表，比如每次取
id BETWEEN 10001 AND 15000的5000行 - 用这批ID拼成
IN查询被驱动表，注意控制IN列表长度，避免超max_allowed_packet - 应用层合并结果，逻辑清晰、内存可控、CPU压力分散
