首先检查MySQL内存配置如innodb_buffer_pool_size、tmp_table_size等是否合理，避免单连接缓冲区过大或总内存超限；再通过SHOW PROCESSLIST和性能视图分析活跃连接与SQL行为，排查高内存消耗查询；结合performance_schema内存摘要和InnoDB状态监控内存分配；最后利用top、dmesg、vmstat等系统工具确认OS层面内存使用及OOM情况，综合定位内存问题根源。
MySQL内存问题通常表现为服务崩溃、响应变慢或系统OOM（Out of Memory）。排查这类问题需要从MySQL内部配置、运行状态和操作系统层面综合分析。以下是具体的排查思路和方法。
检查MySQL内存相关配置
MySQL的内存使用主要由多个参数控制，不合理配置会导致内存占用过高。
重点关注以下参数：
- innodb_buffer_pool_size：这是最大的内存消耗项，建议设置为物理内存的50%~70%。过大会挤占系统其他进程内存。
- key_buffer_size：仅MyISAM引擎使用，若未用MyISAM，可调小至8M~16M。
- query_cache_size：查询缓存，在高并发写场景下可能引发锁争用，MySQL 8.0已移除，建议关闭。
- tmp_table_size 和 max_heap_table_size：控制内存临时表大小，过大可能导致单个查询占用过多内存。
- sort_buffer_size、join_buffer_size、read_buffer_size：这些是每个连接分配的内存，不宜设太大，否则连接数多时总内存飙升。
通过以下命令查看当前配置：
SHOW VARIABLES LIKE ‘%buffer%’;
SHOW VARIABLES LIKE ‘%cache%’;
SHOW VARIABLES LIKE ‘tmp_table_size’;
SHOW VARIABLES LIKE ‘max_heap_table_size’;
分析当前连接与SQL行为
某些SQL语句或大量连接会累积消耗大量内存。
执行以下操作定位问题：
- 查看当前连接数：SHOW STATUS LIKE ‘Threads_connected’; 连接数过高且每个连接分配较多内存缓冲区，容易导致内存耗尽。
- 查看正在运行的查询：SHOW FULL PROCESSLIST; 检查是否有长时间运行、使用临时表或排序的SQL。
- 检查是否频繁创建磁盘临时表：SHOW STATUS LIKE ‘Created_tmp%tables’; 如果
Created_tmp_disk_tables很高，说明内存不足导致临时表写入磁盘，可能需调整tmp_table_size或优化SQL。
监控MySQL实际内存使用
通过性能视图了解内存分配情况。
- 使用
information_schema或performance_schema查看内存事件（需开启）： - 对于InnoDB，查看缓冲池状态：SHOW ENGINE INNODB STATUSG 关注
BUFFER POOL AND MEMORY部分，查看缓冲池使用率、页面数量等。
SELECT * FROM performance_schema.memory_summary_global_by_event_name ORDER BY SUM_ALLOCATED DESC LIMIT 10;
这能显示各类操作的内存分配情况，帮助定位内存热点。
结合操作系统层面分析
MySQL是进程级服务，需结合OS工具判断整体内存状况。
- 使用top -p $(pgrep mysqld) 查看mysqld进程的RES（常驻内存）使用情况。
- 用htop或ps aux | grep mysqld观察内存增长趋势。
- 检查系统是否发生OOM：dmesg | grep -i ‘oom’ 或 journalctl | grep -i ‘oom’ 若发现MySQL被OOM Killer终止，说明内存超限。
- 使用vmstat 1或free -h观察系统swap使用情况，swap频繁读写说明物理内存不足。
基本上就这些。关键是把配置、SQL行为和系统监控结合起来看，找到内存增长的源头。多数情况下是innodb_buffer_pool_size设得过大，或大量连接+大SQL缓冲区导致连接堆积耗内存。调整前建议在测试环境验证，避免影响生产。