确认mysqld被oom killer杀死需执行dmesg -t | grep -i "killed process"，检查输出是否含mysqld、"out of memory: kill process"及时间戳是否与systemctl status mysqld宕机时间一致。
mysqld 被杀，90% 以上不是 MySQL 自己崩了，而是 Linux 内核用 OOM Killer 主动干掉的——它只看谁吃内存多、谁 oom_score_adj 高，不看你是数据库还是脚本。
怎么确认真是 OOM Killer 下的手？
别翻 /var/log/messages，有些系统（如 CentOS 7+、Ubuntu 20.04+）根本不会把 OOM 记进去。唯一可靠路径是：dmesg -T | grep -i "killed process"
重点看三件事：
- 输出里有没有
mysqld或对应 PID - 有没有
Out of memory: Kill process字样 - 时间戳是否和
systemctl status mysqld显示的宕机时间一致
如果看到类似 Killed process 12345 (mysqld) total-vm:2.1g, anon-rss:1.3g，就坐实了。
为什么 innodb_buffer_pool_size 不是越大越好？
它常占 mysqld 总内存的 70% 以上，但设太高会挤占系统空间——内核、glibc malloc、PHP-FPM、宝塔面板自身都要内存。关键不是物理内存总量，而是 MemAvailable：
cat /proc/meminfo | grep MemAvailable —— 这个值才是你敢分给 MySQL 的硬上限。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
常见误判：
- 在云主机（如阿里云共享型、AWS t3）上信
free -h的MemTotal，结果虚高 1–2GB - 设了
innodb_buffer_pool_size = 4G，但机器总共才 4GB RAM，没给 OS 留哪怕 1GB - 容器里跑 MySQL 却没加
--memory=4g，宿主机一 OOM，全盘清算
哪些参数组合最容易触发 OOM？
innodb_buffer_pool_size 是大头，但“配角”加起来更致命。尤其注意这三项乘积：
max_connections = 500-
sort_buffer_size = 4M（每个连接独占） -
tmp_table_size = 512M（一个复杂GROUP BY就可能拉满）
光前两项就吃掉 2GB；再叠加几个大查询，anon-rss 瞬间破 3GB，OOM Killer 立刻点名。
安全建议：
-
innodb_buffer_pool_size≤ 物理内存 50%–60%，且预留 ≥2GB 给系统 -
tmp_table_size和max_heap_table_size统一设为64M（别超128M） -
sort_buffer_size、join_buffer_size保持默认或设为256K/128K，别手抖写4M - 老配置里残留的
query_cache_type=1必须关：设成0
临时救急和长期配置怎么配合？
重启前先压住内存，否则改完配置一启动就失败：
- 在线调小 buffer pool（MySQL 5.7+）：
SET GLOBAL innodb_buffer_pool_size = 2147483648（单位必须是字节，且得是chunk_size × instances的整数倍，默认最小步进 1024MB） - 查进度：
SHOW STATUS LIKE 'Innodb_buffer_pool_resize_status'，别中断连接 - 永久生效仍要改配置文件：
/etc/my.cnf中[mysqld]段写innodb_buffer_pool_size = 2G - systemd 启动的务必补限制：
MemoryMax=3G+MemorySwapMax=3G，防超卖
最后提醒一句：别迷信 oom_score_adj = -1000。设成 -500 是平衡点，-1000 会让内核在真正危机时无法回收，反而拖垮整个系统。
