MySQL 出现内存不足问题时，通常表现为服务崩溃、启动失败、OOM（Out of Memory）被系统杀死，或性能急剧下降。排查这类问题需要从 MySQL 自身配置、运行状态和操作系统层面综合分析。以下是具体排查步骤。
检查 MySQL 配置项是否过高
MySQL 的多个缓冲区和缓存会占用大量内存，若配置不当容易导致整体内存超限。
重点关注以下参数：
innodb_buffer_pool_size：这是最大头的内存消耗者，建议设置为主机物理内存的 50%~70%，避免过高。 key_buffer_size：仅 MyISAM 使用，若表基本为 InnoDB，可设小（如 16M~32M）。 query_cache_size：MySQL 8.0 已移除，低版本建议关闭（设为 0）以避免锁争用和内存碎片。 tmp_table_size 和 max_heap_table_size：控制内存临时表大小，过大会导致单个查询占用过多内存。 sort_buffer_size、join_buffer_size、read_buffer_size 等连接级缓冲：每个连接独占，不宜设大（一般 1M~4M），否则高并发时总内存暴涨。查看当前配置：
SHOW VARIABLES LIKE '%buffer%';SHOW VARIABLES LIKE '%cache%';
SHOW VARIABLES LIKE 'tmp_table_size';
监控运行时内存使用情况
通过性能视图了解实际内存分配情况。
查看当前连接数：SHOW STATUS LIKE 'Threads_connected'; 连接越多，连接级缓冲总开销越大。 检查是否频繁创建磁盘临时表：SHOW STATUS LIKE 'Created_tmp_%tables'; 若Created_tmp_disk_tables较高，说明 tmp_table_size 不足，但盲目调大可能加剧内存压力。 使用 performance_schema 分析内存使用（需开启）： SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED
FROM performance_schema.memory_summary_global_by_event_name
ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 10;
这能定位哪些内部组件占用内存最多。
检查操作系统层面内存状态
登录服务器，使用系统命令查看整体资源。
free -h：查看剩余内存和 swap 使用情况。若 swap 被大量使用，说明物理内存不足。 top 或 htop：观察 mysqld 进程的 RES（常驻内存）占用，对比配置估算值是否合理。 dmesg | grep -i 'oom'：检查是否触发了 Linux OOM Killer，若有输出，说明系统因内存不足杀掉了 MySQL。 cat /var/log/messages | grep -i oom 或 journalctl | grep -i oom：进一步确认 OOM 时间点和上下文。优化建议与调整策略
根据排查结果进行针对性调整。
若 buffer_pool 占用过高，按实际数据量调整，不必盲目设大。 降低连接级缓冲大小，尤其在高并发场景下，每个连接节省 1M 可释放数十 GB 内存。 限制最大连接数 max_connections，防止连接暴增耗尽内存。 考虑启用 innodb_buffer_pool_instances（如 8），减少锁争用，提升效率。 升级服务器内存或优化应用，减少慢查询和全表扫描，降低临时表和排序需求。基本上就这些。关键是把配置和实际负载匹配，避免“堆参数”式优化。定期监控，早发现早调整。
