MySQL内存OOM主因是innodb_buffer_pool_size超可用内存且未预留OS/agent/脚本空间，叠加performance_schema、连接线程等隐性消耗；需以MemAvailable为准校准buffer pool，并监控Innodb_buffer_pool_wait_free及命中率。
innodb_buffer_pool_size 设得太大，是 MySQL 内存爆掉最常见、最直接的原因——不是“不够用”，而是“抢太多”。
为什么调大 innodb_buffer_pool_size 反而会触发 OOM
这个参数不是缓冲池“最小用量”，而是 MySQL 启动时就向操作系统申请的一整块固定内存。它不随负载动态收缩，即使当前只用了 30%，OS 也认为这整块（比如 32G）已被 mysqld 锁死。
- Linux 的 OOM Killer 会按“已分配虚拟内存 × 进程权重”杀进程，
innodb_buffer_pool_size占比越大，mysqld 越容易被选中 - 若机器还跑着 Redis、Java 应用或监控 agent，它们和 MySQL 共享物理内存，但各自“看不见”对方的 buffer pool，极易叠加超限
- MySQL 5.7+ 支持动态调整，但执行
SET GLOBAL innodb_buffer_pool_size = ...会重建整个 buffer pool，期间可能短暂卡顿，且新值必须是innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的整数倍，否则会被向下取整（查SHOW VARIABLES LIKE 'innodb_buffer_pool_size'确认实际生效值）
怎么算出安全的 innodb_buffer_pool_size 值
别套“总内存 × 70%”这种模糊公式。先看真实余量：
- 在 Linux 上跑
free -h，重点看available列（不是free），确保留出 ≥ 2GB 给 OS 和其他服务 - 如果机器有 64GB 总内存，
available常驻 5GB，那innodb_buffer_pool_size最多设到 57GB —— 但实际应更保守，比如 40–48GB - RDS 用户注意：不同版本 MySQL 对该参数有硬性推荐上限（如 32GB 实例建议 ≤21GB），超出部分可能被截断或不生效，以控制台显示为准
- 检查是否启用了
innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup：它们会在重启时把热页序列化到磁盘再加载，若热数据远小于 buffer pool 总大小，反而拖慢启动并占用额外 I/O 缓存
光调 innodb_buffer_pool_size 不够，还得盯住连接数和 per-connection 参数
很多 case 表面是 buffer pool 占得多，实际是 Threads_connected 暴增 + per-connection 缓冲区吃掉的——每个连接默认独占 sort_buffer_size、join_buffer_size、线程栈等，1000 个空闲连接轻松吞掉 4GB+。
- 查真实并发：
SHOW STATUS LIKE 'Threads_connected'，对比max_connections；若长期 >70% 且SHOW PROCESSLIST里大量Sleep状态，说明应用没复用连接或存在泄漏 - 调低
max_connections到合理值（如 300），同时在应用层强制使用连接池（如 HikariCP 的maximumPoolSize=200），并设wait_timeout = 300自动回收空闲连接 -
sort_buffer_size建议保持默认（256KB）或最多设为 1MB；设成 4MB × 500 连接 = 2GB，纯属浪费 - 用
SHOW ENGINE INNODB STATUS\G查Buffer pool hit rate：长期低于 95%，说明 SQL 没走索引或频繁全表扫描，调大 buffer pool 没意义
排查时容易忽略的内存大户
buffer pool 是显性大头，但以下几项常被漏掉，却能悄悄吃掉几个 GB：
-
performance_schema：默认关闭，但一旦开启，本身就会占用数百 MB（尤其table_definition_cache大时）。RDS 5.6 及以下版本关它需重启，5.7+ 可动态SET GLOBAL performance_schema = OFF - 数据字典内存：表数量多（如 20w+）、字段定义复杂、
table_open_cache过大，会导致dictionary memory allocated占用数 GB，这部分不计入 buffer pool 统计 - 临时表内存：
tmp_table_size和max_heap_table_size控制内存临时表上限，但每个连接都可独立申请；若 SQL 频繁 GROUP BY 或 JOIN 大结果集，会快速堆积 - 复制缓存：主从架构下，
gcs_xcom::xcom_cache（Group Replication）或 binlog cache 在高写入场景下也可能占到 1GB+
真正难处理的从来不是 buffer pool 本身，而是它和连接数、per-connection 参数、数据字典规模、复制机制之间的耦合关系——单点调参往往治标不治本，必须结合 SHOW PROCESSLIST、performance_schema.memory_summary_global_by_event_name 和系统级 free/top 交叉验证。
