应先用 ps 或 pmap 查 mysqld 进程 RSS 内存，而非仅调大 innodb_buffer_pool_size；RSS 超物理内存 80% 或远超配置参数总和时，需排查连接泄漏、临时表滥用、performance_schema 开销等隐性内存消耗。
别急着调大 innodb_buffer_pool_size，它很可能是问题的放大器，而不是解药。真实内存溢出往往来自配置失衡或隐性泄漏，调错方向会更快触发 OOM Killer。
先确认是不是真缺内存：看 RSS 而不是看配置
MySQL 报 “Out of memory” 不代表该用的内存没配够，而是它已经吃掉太多，系统扛不住了。必须用系统命令看进程实占：
-
ps -o pid,rss,vsz,comm -C mysqld—— 关键看RSS列（单位 KB），超过物理内存 80% 就危险 - 如果
RSS比你所有显式内存参数加起来（innodb_buffer_pool_size+sort_buffer_size × max_connections+tmp_table_size等）高出一倍以上，说明有连接堆积、临时表滥用或 performance_schema 开销失控 - 容器环境要额外检查：
dmesg -t | grep -i "killed process"，确认是不是被 cgroup OOM 杀的
调小才是最快止损动作：尤其在低配或混部环境
在非专用数据库服务器（比如宝塔共存 PHP/Nginx）、虚拟机、XAMPP 或容器里，把 innodb_buffer_pool_size 设成物理内存的 70% 是高危操作。InnoDB 缓冲池是 mmap 分配的匿名内存，Linux 内核不会优先把它换出，反而会先杀 mysqld。
- 2GB 内存机器：设为
32M最稳妥（XAMPP 默认 128M 就会导致启动失败） - 4GB 内存机器：上限建议
2048M，同时必须同步压低max_connections = 30 - 修改位置必须是 MySQL 实际加载的配置文件：XAMPP 是
XAMPP\mysql\bin\my.ini；Linux 下通常是/etc/my.cnf或/etc/mysql/my.cnf，不是随便哪个my.cnf - 改完记得重启，并用
ps对比RSS是否明显回落
动态调整有硬限制：不是想设多少就生效
MySQL 5.7+ 支持 SET GLOBAL innodb_buffer_pool_size = ...，但不是无条件生效：
- 新值必须是
128MB的整数倍（底层由innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances决定对齐粒度，默认最小步进 8MB，但实际生效仍按 128MB 对齐） - 若设置值小于当前已用内存（比如正在刷脏页），MySQL 会拒绝变更并报错
ER_CHANGE_BUFFER_POOL_SIZE_FAILED - 调整后不会立刻释放/申请全部内存，而是后台逐步迁移页，期间日志会出现
Buffer pool dump completed滚动输出 - 执行后务必查
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'和SHOW ENGINE INNODB STATUS\G中的Buffer pool size是否最终稳定为预期值
真正容易被忽略的是：Buffer Pool 只是内存消耗的一环，sort_buffer_size、tmp_table_size、performance_schema 在高并发下会瞬间反扑。调完 innodb_buffer_pool_size 后，必须同步检查这些线程级参数是否失控——否则刚压下去的 RSS，几分钟内又会涨回来。
