MySQL内存溢出时，首要排查innodb_buffer_pool_size是否过高，它应严格控制在物理内存合理范围内，单机建议≤70%可用内存，混合部署≤50%，并需结合buffer_pool_instances等参数协同优化。
MySQL内存溢出时，innodb_buffer_pool_size 是首要排查项
绝大多数 MySQL 内存溢出（如 OOM Killer 杀进程、系统内存耗尽、Cannot allocate memory 错误）都和 innodb_buffer_pool_size 设置过高直接相关。它不是“越大越好”，而是必须严格控制在物理内存的合理范围内——尤其当服务器还运行其他服务（如 Redis、Nginx、Java 应用）时。
实操建议：
- 确认可用物理内存：用
free -h看available值，而非total；若启用了 swap，也别依赖它缓解 Buffer Pool 压力——InnoDB 不会主动使用 swap，且 swap 会引发严重性能抖动 - 单机纯 MySQL 场景：上限建议 ≤ 70%
available内存；混合部署场景（如 Docker + MySQL 共存）：建议 ≤ 50% - 避免写死绝对值（如
12G），改用比例表达更安全：innodb_buffer_pool_size = 6G→ 改为innodb_buffer_pool_size = 6442450944（字节）或保留数值但加注释说明依据 - 重启前务必验证：修改
my.cnf后，用mysqld --defaults-file=/etc/my.cnf --verbose --help | grep buffer_pool检查是否被覆盖（例如被mysql.server脚本或 systemd 环境变量干扰）
Buffer Pool 分割与实例数设置不当会加剧内存碎片和锁争用
innodb_buffer_pool_instances 控制 Buffer Pool 被划分为多少个独立区域。设得太小（默认 1）会导致高并发下多个线程争抢同一 LRU list 和 chunk mutex；设得太大（如 > CPU 核数）反而增加管理开销、浪费内存对齐空间，并可能触发 malloc 分配失败（尤其在低内存机器上）。
实操建议：
- 实例数应 ≥ CPU 核心数，但 ≤ 8；常见稳妥值是
4或8（取决于内存总量：≥32G 可设 8，≤16G 设 4 即可） - 每个 instance 的最小尺寸是 1GB，所以总
innodb_buffer_pool_size必须 ≥innodb_buffer_pool_instances × 1G，否则 MySQL 启动时会静默降级并报 warning（日志里搜buffer pool size reduced） - 不要为了“看起来更细粒度”而盲目调高该值——它不提升缓存命中率，只影响并发访问效率；命中率看
SHOW ENGINE INNODB STATUS\G中的Buffer pool hit rate
Buffer Pool 预热慢、冷启动抖动大？别只盯 innodb_buffer_pool_dump_at_shutdown
开启 innodb_buffer_pool_dump_at_shutdown 和 innodb_buffer_pool_load_at_startup 确实能加速恢复热点页，但实际效果受限于两个隐藏条件：dump 文件路径权限、以及 dump 时机是否真覆盖了业务高峰热点。
实操建议：
- 确保
innodb_buffer_pool_dump_pct≥ 25（默认 25），否则只 dump 最热 25% 的 page，冷启动后仍大量磁盘读；生产建议设为75或100 - dump 文件默认在
datadir下，名为ib_buffer_pool；检查该文件属主是否为mysql用户，且目录有写权限（否则 shutdown 时不生成，startup 时加载失败也不报错） - 更可靠的方式是定时手动触发：业务低峰期执行
SELECT * FROM sys.innodb_buffer_stats_by_schema;辅助判断热点库表，再用SET GLOBAL innodb_buffer_pool_dump_now=ON;强制 dump，比依赖 shutdown 更可控
为什么调小了 innodb_buffer_pool_size 还 OOM？检查其他内存大户
Buffer Pool 只是 MySQL 内存消耗的大头，但不是全部。当它已合理设置却仍 OOM，大概率是其他参数失控或查询行为异常。
实操建议：
- 重点排查：
sort_buffer_size、join_buffer_size、read_rnd_buffer_size—— 它们是**每连接独占**的，100 个连接 × 4M = 400MB，极易雪崩；建议统一设为262144（256K）起步，按需微调 - 禁用
query_cache_type=OFF（MySQL 8.0 已移除，但 5.7 仍默认 ON）；QC 在高并发下锁竞争剧烈，且缓存失效成本极高 - 检查是否有未限制的
LIMIT查询或SELECT *扫全表：这类查询会把结果集全载入内存（由max_allowed_packet和连接线程堆栈共同承载），比 Buffer Pool 更隐蔽地吃光内存 - 用
SHOW PROCESSLIST+information_schema.PROCESSLIST结合sys.memory_by_thread_by_current_bytes视图定位内存占用 TOP 线程
Buffer Pool 调优本质是权衡：既要足够大以减少 I/O，又不能挤占系统和其他进程的生存空间。最危险的操作不是设小了，而是设大了还忽略了并发线程内存、排序缓冲区这些“隐形巨兽”。
