确认是否被oom-killer杀掉需先执行dmesg -t | grep -i "killed process" | grep mysqld并核对时间戳，同时检查/var/log/messages中oom_kill或badness记录；若无则排除oom，再查memavailable值减去2–4gb作为innodb_buffer_pool_size安全上限，且在线调整须用字节单位并为128mb整数倍；performance_schema和触发器、连接级缓冲（sort_buffer_size等）及max_connections均是隐性内存大户，需协同监控与限制。
确认是不是真被 oom-killer 杀掉的
别一看到 MySQL 崩了就调参数，先验证是不是系统级 OOM。执行 dmesg -T | grep -i "killed process" | grep mysqld，如果有输出且时间戳和 MySQL 崩溃时间吻合，才是真被干掉；否则可能是磁盘满、网络中断或配置语法错误。
同时查 /var/log/messages 或 /var/log/syslog，搜 oom_kill 或 badness 字样。没找到这些记录，就别硬往内存上扯。
别信 free -h 的 MemTotal，盯紧 MemAvailable
云主机（比如阿里云共享型、AWS t3）的 MemTotal 是虚的，真正能分给 MySQL 的硬上限是：cat /proc/meminfo | grep MemAvailable。这个值减去 2–4GB（OS + agent + 备份脚本）才是安全边界。
innodb_buffer_pool_size 必须 ≤ 这个安全边界，否则就是埋雷。设成 2G 或 2048M 在配置文件里可以，但在线调整必须用字节单位（比如 2147483648），且必须是 128MB（即 134217728 字节）的整数倍，否则会静默截断或报错。
performance_schema 和触发器是隐形吃内存大户
开了 performance_schema 且启用了 memory/% = COUNTED，memory/sql/sp_head::main_mem_root 在重放带几十个触发器的 binlog 时，单次就能吃掉几 GB。这不是 buffer pool 的锅，而是 SQL 线程加载触发器上下文导致的。
查实时占用：SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/sql/sp_head%' ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 1。如果这个值排前三且持续上涨，基本就是它在捣鬼。
临时缓解办法：
- 关掉 performance_schema：
SET GLOBAL performance_schema = OFF（需重启才永久生效） - 把
table_open_cache_instances从默认 16 改成 1，减少每个 instance 缓存一份 sp_head 实例 - 注释掉非必要触发器，尤其那些逻辑里有
SELECT ... INTO @var或拼接长字符串的
连接级缓冲叠加起来很吓人
sort_buffer_size、join_buffer_size、read_buffer_size 都是“每连接”分配的，不是全局共享。设成 4MB，有 500 个活跃连接，光这三项就吃掉 6GB。
tmp_table_size 和 max_heap_table_size 取小值，控制内存临时表上限。设太大（如 512MB）+ 复杂 GROUP BY 查询多 → 单查询就占几百 MB。
max_connections 要压住，宝塔面板下建议设为 50–100；小内存机器（≤2GB）别硬塞 1.5G 给 buffer pool，顺手清掉已弃用的 query_cache_size 和残留的 key_buffer_size。
buffer pool 不是唯一凶手，但它是最大头；真正要命的是 buffer pool 吃满后，其他内存组件没留余量，一起把系统推过临界点。调参前先看 ps aux --sort=-%mem | head -5，确认是不是 mysqld 真排第一——如果不是，先杀掉那个吃内存的 Python 或 Java 进程。
