当 MySQL 导致服务器 CPU 和内存双双达到 100% 并触发 OOM Killer 时，说明数据库正处于极端的资源耗尽状态。这不仅会导致数据库崩溃，还会严重影响整个服务器的稳定性。
要彻底解决这个问题，建议按照以下“三步走”策略进行排查和优化：

第一步：紧急止血（恢复服务）
在系统濒临崩溃时，首先需要让服务器恢复可用状态：
终止异常会话：登录 MySQL，使用 SHOW PROCESSLIST 或查看 performance_schema，找出消耗内存大、执行时间长的异常查询或事务，果断使用 KILL 命令终止它们。
检查并重启服务：如果 MySQL 已经被 OOM Killer 杀掉，在确认内存释放后重启数据库服务。

第二步：内存优化（解决 OOM 崩溃）
内存耗尽通常是 MySQL 内存配置不合理或隐性消耗过大导致的，需从以下几个维度调整：
调低核心缓冲池：innodb_buffer_pool_size 是内存占用的大头。建议将其设置为物理内存的 50%~70%，必须给操作系统和其他服务预留至少 1GB~2GB 的空间。
限制连接数与单连接缓冲：高并发下，每个连接都会分配独立的内存缓冲区。建议合理调低 max_connections（如设为 100~300），并缩小 sort_buffer_size、join_buffer_size 和 tmp_table_size（建议 tmp_table_size 不超过 64M，强制大结果集走磁盘临时表，宁慢勿崩）。
关闭高内存消耗组件：对于小内存服务器，MySQL 8.0 默认开启的 performance_schema 会占用数百兆内存，建议将其设为 OFF；同时检查并关闭 innodb_buffer_pool_dump_at_shutdown，防止重启时额外消耗内存。
增加 Swap 兜底：如果服务器没有 Swap 分区，建议创建一个 2GB 左右的 Swap 文件作为内存缓冲，避免内核在内存耗尽时直接“杀人”。

第三步：CPU 与 I/O 优化（解决 100% 负载）
CPU 和内存同时飙升，往往伴随着严重的磁盘 I/O 瓶颈（例如内存不足导致临时表频繁落盘，引发大量物理读写）：
诊断 I/O 瓶颈：使用 iostat -x 1 30 命令观察 %iowait 和 %util 指标。如果 %iowait 持续大于 20% 或 %util 大于 80%，说明磁盘已严重饱和，这是导致 CPU 飙升的直接原因。
优化 I/O 参数：如果使用的是 SSD 磁盘，可以适当调高 innodb_io_capacity 和 innodb_io_capacity_max，并增加 innodb_write_io_threads 和 innodb_read_io_threads 的数量，提升刷脏和读取效率。
优化慢查询与索引：CPU 100% 的根本原因通常是缺失索引导致的全表扫描或极其复杂的 JOIN 查询。需开启慢查询日志（slow.log），找出执行时间长或频次极高的 SQL，为其添加合适的索引，或拆分大 JOIN 查询。

终极建议：
如果经过上述参数调整和 SQL 优化后，服务器依然频繁出现资源打满的情况，说明当前的硬件规格已经无法满足实际的业务体量。最直接有效的解决方案是升级服务器的物理内存（RAM）和 CPU 核心数，或者将数据库迁移至独立的云数据库（RDS）实例以实现资源隔离。

针对您 2核2G 的 VPS 服务器，这样一个典型的“极限配置”。在这种环境下运行 MySQL，绝对不能使用默认配置，否则极易触发 OOM（内存溢出）导致数据库被系统强制杀死。
结合您的服务器情况，为您量身定制了以下优化方案及 my.cnf 配置示例：
. 核心 my.cnf 配置示例
请将以下配置应用到您的 MySQL 配置文件（通常为 /etc/my.cnf 或 /etc/mysql/my.cnf）的 [mysqld] 模块下。此配置的核心逻辑是：大幅压缩内存缓冲池、限制并发连接数、关闭高开销组件：

[mysqld]
# ========== 内存核心优化（针对2G服务器） ==========
# InnoDB缓冲池：建议设为 512M（若同机运行Java/Nginx，建议降至 384M~512M）
innodb_buffer_pool_size = 512M
innodb_buffer_pool_instances = 1 # 内存小于1G时，实例数必须设为1
innodb_log_file_size = 64M # 适当减小Redo Log大小
innodb_flush_method = O_DIRECT # 减少内存双重缓存

# 限制单连接内存消耗，防止高并发撑爆内存
tmp_table_size = 32M
max_heap_table_size = 32M
sort_buffer_size = 256K
read_buffer_size = 128K
read_rnd_buffer_size = 128K
join_buffer_size = 256K

# ========== 连接与并发控制 ==========
max_connections = 50 # 严格限制最大连接数，避免耗尽内存
thread_cache_size = 4
table_open_cache = 200
key_buffer_size = 16M # MyISAM键缓存（不用MyISAM可设为8M）

# ========== 关闭高开销模块 ==========
performance_schema = OFF # 关键！关闭性能模式可节省大量内存
skip-name-resolve # 跳过DNS反向解析，节省连接时间

# ========== 字符集与日志 ==========
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
slow_query_log = ON # 开启慢查询日志，方便排查CPU 100%问题
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2 # 超过2秒的查询记录为慢查询

. 系统级配合操作（防 OOM 必做）
除了调整 MySQL 参数，您还需要在操作系统层面做好防护：
创建 Swap 交换分区：物理内存不足时，Swap 是防止 OOM Killer 杀进程的最后一道防线。建议创建一个 2GB 的 Swap 文件：
dd if=/dev/zero of=/swapfile bs=1M count=2048
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo ‘/swapfile none swap sw 0 0’ | sudo tee -a /etc/fstab

调整 Swappiness 参数：让系统尽量优先使用物理内存，把 Swap 作为兜底，避免频繁换页导致磁盘 I/O 飙升。
sysctl vm.swappiness=10

. 特别注意事项
同机部署警告：如果您在这台 2G 服务器上同时运行了 Java (Spring Boot)、Nginx 或 Redis，请务必限制 Java 的 JVM 堆内存（如 -Xmx512m），并将 MySQL 的 innodb_buffer_pool_size 进一步降至 384M 左右，否则总内存需求会超过 2GB 导致崩溃。
适用场景：2核2G 配置仅适合个人学习、开发测试环境、低并发的内部管理系统或小型博客（日活几十人、单表数据量百万级以内）。不适合高并发 API 接口或复杂报表查询。
验证生效：修改配置后，务必重启 MySQL 服务，并登录数据库执行 SHOW VARIABLES LIKE ‘innodb_buffer_pool_size’; 验证参数是否生效。
如果业务量有增长趋势，建议优先考虑将数据库迁移到云托管服务（如阿里云 RDS 共享型），或者将服务器升级到 2核4G 的“舒适区”配置。