首先检查 MySQL 配置参数如 innodb_buffer_pool_size、连接级缓冲等是否过高，避免内存超配；接着通过 SHOW STATUS 和 performance_schema 查看运行时内存使用及临时表创建情况；再用 free、top、dmesg 等系统命令分析内存状态和 OOM 记录；最后根据实际负载调整配置，降低缓冲大小、限制最大连接数、优化查询，确保资源配置与业务需求匹配，防止内存不足。
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），减少锁争用，提升效率。
- 升级服务器内存或优化应用，减少慢查询和全表扫描，降低临时表和排序需求。
基本上就这些。关键是把配置和实际负载匹配，避免“堆参数”式优化。定期监控，早发现早调整。
