答案是buffer pool命中率低于95%导致join查询耗时波动；需执行show global status like 'innodb_buffer_pool_read%'并计算(1 - reads/requests) × 100，若低于90%则说明缓存水位严重不足，应基于free -h的available内存将innodb_buffer_pool_size设为50%~75%。
重复执行同一 JOIN 查询却耗时忽高忽低，大概率不是 SQL 写得有问题，而是 InnoDB Buffer Pool 缓存没兜住——第一次查要从磁盘读页，后续查如果页还在内存里就快得多；但一旦被挤出、或根本没缓存住，就会反复掉盘，时间毛刺就出来了。
怎么看 Buffer Pool 命中率是否拉胯
别信“好像还行”，直接算数字。执行：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';
拿到两个值：Innodb_buffer_pool_reads（真去磁盘读的次数）和 Innodb_buffer_pool_read_requests（总请求次数），代入公式：
(1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) * 100
结果低于 95% 就得动手，低于 90% 属于明显资源不足。注意：这个命中率是全局统计，不是单次查询的，但能反映整体缓存水位是否健康。
为什么 JOIN 查询特别容易暴露命中率问题
多表 JOIN 往往涉及大量数据页随机访问，尤其是驱动表小、被驱动表大时，优化器可能走 Nested Loop，每条驱动行都要去被驱动表捞匹配行——如果被驱动表的索引页或数据页不在 Buffer Pool 里，就得反复触发磁盘 IO。
- JOIN 字段没索引 → 全表扫描 → 大量冷页加载，直接冲垮缓存
-
join_buffer_size设置过小 → MySQL 改用 Block Nested-Loop（BNL），中间结果写临时块，IO 次数翻倍，缓存更难维持 - 一次 JOIN 扫了几十万行 → 热数据页被新页批量挤出，后续查询立刻降速
改 innodb_buffer_pool_size 的实际约束
这不是调个参数重启就完事的事，有硬性限制：
- 必须基于
free -h看到的available内存来定，不是 total；设超了会导致系统 OOM 或 MySQL 启动失败 - 建议值为可用内存的 50%~75%，比如
available是 32G，就设 16G~24G - MySQL 5.7+ 虽支持
SET GLOBAL innodb_buffer_pool_size动态调整，但只允许按当前大小的整数倍扩容（如 2G → 4G → 8G），且仍需足够空闲内存；失败时静默忽略，不报错也不提示 - 线上改必须选维护窗口，因为扩容过程会短暂卡顿，且旧页不会自动迁移，新 buffer pool 需要预热才能达到稳定命中率
真正卡住性能的往往不是 JOIN 写法本身，而是 Buffer Pool 没撑住基础水位——命中率掉到 90% 以下时，再怎么重写 SQL、加索引，都只是在给磁盘 IO 打补丁。
